After using Clojurescript for some time, I don't even understand anymore what kind of problems Typescript supposed to be solving. Sometimes it feels it causes more headaches, to be honest.
TypeScript’s quirks: How inconsistencies make the language more complex
191–200 of 216 posts
Re: TypeScript’s quirks: How inconsistencies make the language more complex
#192Earlier quoted context omitted.
TypeScript’s goal isn’t absolute type safety, the goal is feedback (eg code completion) and earlier detection of many errors.
Yes, I realize that's not the goal which is why I said 'by choice'. I just think it's not the right approach ultimately. Other safer languages also reach the goals of code completion and error detection.
Most of the highly typed languages actually do a poor job with code completion and error handling, they were specifically designed with safety in mind and other aspects of the type system are given only secondary attention. TyoeScript is nice because it focuses on where type systems are really useful (feedback) as a first concern.
Re: TypeScript’s quirks: How inconsistencies make the language more complex
#193Earlier quoted context omitted.
This is absolutely false all type checking in basically every typed language happens precompile time. There is no trade-off here. You completely don't understand.
There's a thing called dynamic type checking. It's literally all type checking done at runtime. Even for mostly static typed languages you may want to lookup what a downcast is, it's not obscure.
I'm not talking about type checking with your run time code. Obviously this is exists. My mistake with the wording.
I am referring to the topic the poster is talking about, that is, type checking with type script and the precompile type checker of almost all statically typed languages.
The precompile type checks do not need run time code. These are separate things executed at separate times AND really you can get by with 100% static.
Re: TypeScript’s quirks: How inconsistencies make the language more complex
#194Earlier quoted context omitted.
Some Typescript value added: - Living documentation: types are a clear description of how your code and its data are laid out, and this structure is kept always up-to-date with the code, regardless of future changes. If the "documentation" (the typing) is wrong, the compiler will complain. - Better tooling: autocomplete, more robust auto-refactoring - Elimination of an entire class of bugs. This class may include: 1.…
Lets be honest here, these reasons are really weak. Living documentation - TypeScript is less readable. There is more stuff you have to read. Stuff that isn't even relevant. I see a "cars" variable. Oh no, I don't know what type it is, I am going to have a panic attack. Don't worry that cars.map((c) => c.model); is the next line or whatever. What type is it, I must know! auto-refactoring.. yeah we all trust that. Unt…
I get the impression you either don’t have much experience with Typescript or haven’t fully grokked it’s workflow, and have prematurely made up your mind. Your autocomplete comment for instance shows you aren’t aware of the extent to which Typescript vastly improves autocomplete.
Regarding typing at the boundaries, this is precisely where typescript shines. The types exist whether they are documented explicitly in your code (in the form of interfaces, types, protocols, etc), or not. This is where the documentation aspect come in to play - it is far easier to read a type definition than having to chase up API documentation, mentally parse tests, or console logging out api responses, to understand your boundary. Your refactoring argument is a strawman, because you wouldn’t just go and refactor names of things at the boundaries of your code in typescript, or any other language, without understanding the API spec. What typescript gives you is precisely the ability to refactor at the boundary when the spec changes and be much more confident that your changes aren’t going to break a whole bunch of thing, especially when it comes to the “class of bugs” that literally every JavaScript developer has dealt with, whether you are aware of them or not.
Re: TypeScript’s quirks: How inconsistencies make the language more complex
#195Earlier quoted context omitted.
Yes, I realize that's not the goal which is why I said 'by choice'. I just think it's not the right approach ultimately. Other safer languages also reach the goals of code completion and error detection.
Most of the highly typed languages actually do a poor job with code completion and error handling, they were specifically designed with safety in mind and other aspects of the type system are given only secondary attention. TyoeScript is nice because it focuses on where type systems are really useful (feedback) as a first concern.
Fortunately, the typed AltJS language with the highest interest levels after TypeScript actually has really good code completion and error reporting :-)
Oh, and build speeds so fast that it's blink-and-you-miss-it. I think that's a pretty important part of useful feedback (and one that I hear TypeScript is not that great at).
Re: TypeScript’s quirks: How inconsistencies make the language more complex
#196Earlier quoted context omitted.
Most of the highly typed languages actually do a poor job with code completion and error handling, they were specifically designed with safety in mind and other aspects of the type system are given only secondary attention. TyoeScript is nice because it focuses on where type systems are really useful (feedback) as a first concern.
Fortunately, the typed AltJS language with the highest interest levels after TypeScript actually has really good code completion and error reporting :-) Oh, and build speeds so fast that it's blink-and-you-miss-it. I think that's a pretty important part of useful feedback (and one that I hear TypeScript is not that great at).
Which language is that? Reason? How is its code completion experience anyways?
TypeScript has a dog of a compiler, I'll give you that. But that wasn't what I was referring to.
Re: TypeScript’s quirks: How inconsistencies make the language more complex
#197Well, typescript is constantly improving over the years, witch each release you are able to represent more real-world JS patterns and type system is getting more strict options. So this 3 points from article might be improved in future.
About the point the article makes:
1) I remember when excess property check was introduces I was really happy! Because I remembered bug that would be caught with it. I had some interface with optional properties in common library and I renamed property name. Of course when I updated this library in another project I didn't get any compile errors because this was optional property and now I was just passing some extra property which was ignored. Excess property check would have found it because I was passing object literal.
Structural typing is great choice in Typescript because it's basically type-safe duck-typing which is used everywhere in Javascript projects. It's not uncommon to have one component that accept objects with some properties but this object contains many extra properties because it came from different component and these properties are used elsewhere. It's standard pattern in Javascript world. But when your function requires some object of given shape and you are creating this object right now using literal syntax, then it's really likely that you made a mistake. Why create extra properties for just created object when you clearly see they are additional? And I read that Typescript teams is very happy with this feature[0].
However, excess properties check is great but useful only on call side. I cannot say that my function doesn't accept extra parameters. I would really love to get Exact types[1]. Which would allow me to force not having extra parameter in passed object.
2) As mentioned in article, Flow decided to have classes nominally typed. In Typescript everything is structurally typed so it's actually more consistent ;) I really hope we'll get nominal typing and opaque types sometime in future. I read TS team was thinking a lot how to do this. I don't remember what is the current status of this.
3) For me it's more problematic that Typescript doesn't narrow types of an union when you do conditional check. The reason is that in general it is unsound (but I think it would not be if you had only union of Exact types, that's another reason why I would love to have Exact types!).
Example in article doesn't have this problem so I guess this could have been improved. Sound like minor issue for me but maybe author could create suggestion on github to improve it and allow discriminator to be nested?
[0] https://github.com/Microsoft/TypeScript/issues/12936#issueco... [1] https://github.com/Microsoft/TypeScript/issues/12936
Re: TypeScript’s quirks: How inconsistencies make the language more complex
#198Earlier quoted context omitted.
As a long time TypeScript user, I do think this is a design mistake with the language. For example, it breaks instanceof checks. However: - The language primarily uses structural typing. If two classes are compatible, it's not completely unreasonable to expect them to also behave in a structural way (though I would prefer them not to). - Adding a private field to a class makes it work as a nominal type ( https://mich…
taking full advantage of ADTs What? There is no clean way to switch on the types of an ADT on typescript, I believe.
Well discriminated unions are TypeScript's implementation of ADTs (but whether they are "clean" is could be debated)
Re: TypeScript’s quirks: How inconsistencies make the language more complex
#199These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…
Structural typing has the benefit of making it easier to code to an interface and reminds me of Go. If you have a function that requires a method off a class (say, `poop`), then rather than declaring it to accept `Cat | Dog` (or overload it, in e.g. Java), you code it to accept an object with a single function (`pooper: { poop: VoidFunction}`). Then anything that implements it can use it, testing is typed and easy, and changing the class is less likely to affect the consuming method.
Its such a powerful pattern, I'm a bit surprised to see so much negativity about it. I'm aware there's alternatives and reasoned opinions, but I bet a significant number of people have never seen or programmed in this style and aren't aware of what they are missing. For me, I can't imagine using another typed language that doesn't support implicit interfaces in this manner.
Re: TypeScript’s quirks: How inconsistencies make the language more complex
#200Earlier quoted context omitted.
Fortunately, the typed AltJS language with the highest interest levels after TypeScript actually has really good code completion and error reporting :-) Oh, and build speeds so fast that it's blink-and-you-miss-it. I think that's a pretty important part of useful feedback (and one that I hear TypeScript is not that great at).
Which language is that? Reason? How is its code completion experience anyways? TypeScript has a dog of a compiler, I'll give you that. But that wasn't what I was referring to.
Yup! See:
- https://reasonml.github.io/docs/en/editor-plugins
- https://reasonml.github.io/docs/en/faq#why-are-bucklescript-...
- Oh, and a really fun one from TypeScript: https://news.ycombinator.com/item?id=20045066