I don't understand this type of cynical criticism. You don't have to use features you believe are "so complicated". Just don't use them. You said you love typescript, and everything you love about typescript remains intact to your satisfaction. It's not as if these features emerge spontaneously from a vacuum, the typescript team is working with the community to address specific needs. You didn't even offer any specific criticisms, just a vague dismissal. Just don't use it.
> I don't understand this type of cynical criticism.
I don't think my comment sounds cynical.
> You don't have to use features you believe are "so complicated".
One has to be fluent with reading type definitions thus have good understanding of the type syntax. I must admit, from time to time I could not make sense of them easily when reading declaration files from third parties.
You don't typically need to examine 3rd party types, consuming them requires little cognitive effort because the IDE/typechecker will generally tell you everything you need to know at the consumption site.
If you ever do have to dig into a really complex type, that might be painful, but keep in mind that the reason we have more sophisticated types is so that we can maximize correctness and reduce the chance of bugs, the fact that you're getting a type error at all means whatever you wanted to do is definitionally unsafe, so it's good that typescript is empowered to tell you not to do this, even if you don't immediately understand why.
> You don't typically need to examine 3rd party types, consuming them requires little cognitive effort because the IDE/typechecker will generally tell you everything you need to know at the consumption site.
Yes you do, you need to be able to read complex type signatures in order to know what a function or a method accepts, and for that you need to understand Typescript's type syntax, it what it is all about at first place. In case you have a compiler error you need to understand how the type system works to make sense of an error. You can't deny that simple fact, that's the whole point of typescript.
That said, you're still generally stuck between a rock and a hard place when it comes to a complicated type definition as the non-annotated alternative (e.g. in a dynamically-typed language) isn't necessarily any less obtuse.
Lots of people simply prefer to know at compile time that their assumptions were wrong than having to reverse-engineer how they were wrong from stack traces at runtime.
> Yes you do, you need to be able to read complex type signatures in order to know what a function or a method accepts
If you don't understand the type of input that's appropriate for a function, a lack of type annotations does not increase your understanding, instead, your incorrect assumptions are literally left unchecked to wreak havoc in live systems. Like I said, it's better that typescript stop you from doing the wrong thing even if you don't immediately understand why it's wrong, but when in doubt most people just check the relevant documentation, same as if they lacked type annotations.
You're entirely missing the point of my initial comment, which is about the complexity of Typescript's type system since it has to be able to represent a large set of complex types since dynamic languages such as Javascript are highly polymorphic. And next time stop accusing people of cynicism randomly.
Chiding a static type checker as a dynamic language based on the sophistication of its type system reads like a cynical joke to me.
I didn't miss your point, but maybe I didn't explain mine clearly enough. You don't have to use complex types, even with 3rd party libraries, just figure out what goes into the function the same way you would if there were no type annotations.
> Chiding a static type checker as a dynamic language based on the sophistication of its type system reads like a cynical joke to me.
And that's not what I said. Stop trying to pick up a fight with me or something by misrepresenting what I've said just for the sake of hearing yourself taking, it reflects bad on you, especially you doubling down.
I only talked about the fact that there is a limit to the degree of complexity Typescript types until it itselfs turns into a javascript interpreter. your answers have absolutely nothing to do with that matter.
At the usage site generics can usually be fully inferred, so something that uses these features may look like a horror show at the implementation site, but when you actually use it it will just look like normal string literal types.
> One has to be fluent with reading type definitions thus have good understanding of the type syntax. I must admit, from time to time I could not make sense of them easily when reading declaration files from third parties.
That makes sense when comparing it to other languages, but compared to JavaScript: those type definitions are a pure bonus? In other words, if they'd have been written in JavaScript you'd still have to make sure to pass in the correct data, but you'd have only the documentation to guide you there.
(Of course, if you yourself are using TypeScript, you do have to know how to make sure that TypeScript knows that you're passing in the correct data. But the flip side is that the more complex types will allow for better inference that helps your editor to provide better guidance on how to give it the correct data.)
I think is valid criticism ... even if you pick a subset sometimes the types are "forced on you" by libraries or even by code written by coworkers.
TypeScript advanced types are there to model existing JavaScript codebases, but when designing software from scratch I've seen that is too tempting to go crazy with the types, ending with something pretty messy (JavaScript! :-).
All that flexibility only has use when the TypeScript code needs to interact with something terribly unruly: JavaScript code or some API that isn't typed properly. While it's nice that you can model in your code, it brings the distinct possibility that people will start using it to write very sloppy types and/or patch things up afterwards, leading to worse code.
