4 ms·

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 types

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.

throw_m239339 6y ago
> 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.
- root_axis 6y ago
  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.
  - throw_m239339 6y ago
    > 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.
    - tengbretson 6y ago
      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.
    - hombre_fatal 6y ago
      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.
    - root_axis 6y ago
      > 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.
      - throw_m239339 6y ago
        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.
        root_axis 6y ago
        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.
- Vinnl 6y ago
  > 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.)
emmanueloga_ 6y ago
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! :-).
tgv 6y ago
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.

throw_m239339 6y ago

> 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.

root_axis 6y ago
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.
- throw_m239339 6y ago
  > 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.
  - tengbretson 6y ago
    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.
  - hombre_fatal 6y ago
    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.
  - root_axis 6y ago
    > 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.
    - throw_m239339 6y ago
      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.
      - root_axis 6y ago
        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.
Vinnl 6y ago
> 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.)

emmanueloga_ 6y ago

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! :-).

tgv 6y ago

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.