4 ms·
This is actually why I stopped using it. Forcing types on a dynamic language like this seems to inevitably lead to really, really complex type definitions which
by mslm 6y ago
This is actually why I stopped using it. Forcing types on a dynamic language like this seems to inevitably lead to really, really complex type definitions which just confuse things tremendously. It almost seems easier and better to just straight up use JSDoc with some good standard documentation to back it.
- ht85 6y agoCould you give an example? In years of using TS I have had to craft a few exotic generics, but have otherwise never ran into "really complex" types.
- mslm 6y agoMy point is obviously subjective, so you may not agree, and we may have different tastes for what simplicity/complexity looks like. https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/lodash https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast... felt like to me as one popular example for what should be really simple in practice.
- ht85 6y ago> what should be really simple in practice I thought you were talking about types in your own code. Lodash being a large, heavily overloaded and generic library it seems fair that the definitions are complex. When it comes to external code like that, I don't think you can argue against the value of intellisense and safety (especially when upgrading versions). Those are in my opinion the biggest benefits of having strong types.
- didibus 6y agoIt could depend on the alternative proposed. Adding types to dynamic languages might actually exhibit this behavior, of inevitably leading to really, really complex type definitions which just confuse things tremendously. In your case, your alternative is back to untyped, unsafe JavaScript. Maybe that's not so much better. Another alternative would be to move to a language designed with types in mind from the get go, say OCaml (with ReScript) or Java (with JSweet), or others. Bottom line, I think that claim is still true: "Forcing types on a dynamic language like this seems to inevitably lead to really, really complex type definitions which just confuse things tremendously" But if that is a good or bad trade off for you to make, I think that's very contextual, it depends. Maybe that's okay for someone, and they'll use TypeScript. Maybe that's not okay, and they'll go back to JavaScript. Maybe they'll instead explore a ground up typed lang like Java.
- pragmatic 6y agoAngular + rxjs. You end up with write only code that while typed is overly complicated.
- gavinray 6y agoIt's more characters/more noise to the code to add a JSDoc comment block than it is to add a colon & typename next to the variables/values they belong to.
- mslm 6y agoDifferent things; the JSDoc is purposely bloated-looking on an initial generation because it's meant to give you the space to detail out the semantics of the parameters. You would frankly have to do the same thing with any type system anyway, JSDoc or similar just gives you that combined without any build system or tooling.
- hajile 6y agoTypes say what, docs say why. The semantics of a number or a string aren't described by their basic type.