4 ms·

I was hesitantly open to TS when the hype was first ramping up. The team I was on (and I've seen this in lots of code elsewhere too) was doing stuff like this:

I was hesitantly open to TS when the hype was first ramping up. The team I was on (and I've seen this in lots of code elsewhere too) was doing stuff like this: declare let myColor: Color | undefined; Suddenly everything turned into Java with signatures cascading endlessly. I'm not blaming TS, it's more of a.. lack of faith to make the full jump? Or limitation of the underlying Javascript? This problem should be solved with having multiple function signatures, in the example above one with and one without the Color param. I've been toying with Erlang for years, once I grokked how they flow control can be done via different method signatures, the Other Way started looking really inadequate.

gagege 6y ago
This is my problem with TS. The underlying JavaScript peeks it's gross head through the cracks way too much. I end up not bothering with types since they're often wrong at runtime anyway.
munchbunny 6y ago
If "| undefined" is spreading through your code like a virus in cases where it's not actually optional, then I'd argue that the problem is upstream where the data is ingested, and the code should be enforcing "must be defined" at input validation so that you can carry a clean "Color" type everywhere else. If it's about optional parameter weirdness and TypeScript's lack of method overloading, I suspect that's inherited from JavaScript's laxness with method signatures. I don't like it either.
- zaccusl 6y ago
  TypeScript does have method overloading same as other typed languages (except you have to do runtime checks, but that is a JavaScript limitation).
  - munchbunny 6y ago
    > except you have to do runtime checks, but that is a JavaScript limitation IMO not having to do runtime checks is a big part of the value proposition of method overloading the way many languages do it. Whether or not it’s a limitation inherited from JavaScript, it’s still really klunky compared to other mainstream languages. It’s one of the few things that I actually dislike about TypeScript, despite overall loving it.
jdxcode 6y ago
assuming you meant let myColor: Color | undefined; I don't understand what the problem is. Native JS would require you to define the starting scope of the variable (unless you're relying on global scope!). Then you declare what the type is: Color or undefined. The state of the variable can be one of two things. Perhaps I've been writing TS for too long but I think I'm missing the problem here.
- tomca32 6y ago
  The problem is that if anything can be undefined, then you don't really have a big typing advantage over regular JavaScript. It's just like being in Java land where typing adds a lot of boilerplate to the code, but you still have to do null checks everywhere.
  - symlinkk 6y ago
    That’s a problem with your codebase, not with TS.
    - deckard1 6y ago
      That's the crux of this entire debate. The benefit of a type system is that it provides an organizational framework for code bases that need it (i.e. multi year projects involving a rotating set of developers). That's the only argument for a type system that I agree with (I don't believe it reduces bugs or anything like that, and from what I've seen there are zero studies that conclude such nonsense... this is a 40+ year debate we're talking about). Structural type systems with type inference don't do that. I can't look at your code on Github and know what the code is doing. There is not enough information there. Contrast that with nominal type systems where everything I need to know about a function is right there. I don't need an IDE or external tooling to guide me. It's a true mystery how people think they are reviewing pull requests written in TypeScript and actually doing their job correctly. If you so much as have a single @ts-ignore or "any" in your code base, then all bets are off on correct behavior. TypeScript diminishes the point of type systems by giving the developer too many escape hatches. You ever see a developer abuse the non-null assertion operator in a case where it's not at all true that the value is not null, but the developer doesn't care because they just want to make the compiler happy? Yeah. I have. Then you have to explain the purpose of the non-null assertion operator and that goes about as well as you can imagine. If a type system isn't helping you understand your code or organize your code, then it's all rather pointless. TypeScript is incredibly complex. How many people using TypeScript can tell you something as basic as the difference between "interface" and "type"? And try to describe the difference without using sentences such as "well, originally..." and "back in 2017...". edit: Oh, and in case anyone thinks I'm being pedantic on that last point, check out this absolute shit show: https://stackoverflow.com/questions/37233735/interfaces-vs-types https://stackoverflow.com/questions/37233735/interfaces-vs-t... Keep scrolling down for ultimate depression.

gagege 6y ago

This is my problem with TS. The underlying JavaScript peeks it's gross head through the cracks way too much. I end up not bothering with types since they're often wrong at runtime anyway.

munchbunny 6y ago

If "| undefined" is spreading through your code like a virus in cases where it's not actually optional, then I'd argue that the problem is upstream where the data is ingested, and the code should be enforcing "must be defined" at input validation so that you can carry a clean "Color" type everywhere else. If it's about optional parameter weirdness and TypeScript's lack of method overloading, I suspect that's inherited from JavaScript's laxness with method signatures. I don't like it either.

zaccusl 6y ago
TypeScript does have method overloading same as other typed languages (except you have to do runtime checks, but that is a JavaScript limitation).
- munchbunny 6y ago
  > except you have to do runtime checks, but that is a JavaScript limitation IMO not having to do runtime checks is a big part of the value proposition of method overloading the way many languages do it. Whether or not it’s a limitation inherited from JavaScript, it’s still really klunky compared to other mainstream languages. It’s one of the few things that I actually dislike about TypeScript, despite overall loving it.

jdxcode 6y ago

assuming you meant let myColor: Color | undefined; I don't understand what the problem is. Native JS would require you to define the starting scope of the variable (unless you're relying on global scope!). Then you declare what the type is: Color or undefined. The state of the variable can be one of two things. Perhaps I've been writing TS for too long but I think I'm missing the problem here.

tomca32 6y ago
The problem is that if anything can be undefined, then you don't really have a big typing advantage over regular JavaScript. It's just like being in Java land where typing adds a lot of boilerplate to the code, but you still have to do null checks everywhere.
- symlinkk 6y ago
  That’s a problem with your codebase, not with TS.
  - deckard1 6y ago
    That's the crux of this entire debate. The benefit of a type system is that it provides an organizational framework for code bases that need it (i.e. multi year projects involving a rotating set of developers). That's the only argument for a type system that I agree with (I don't believe it reduces bugs or anything like that, and from what I've seen there are zero studies that conclude such nonsense... this is a 40+ year debate we're talking about). Structural type systems with type inference don't do that. I can't look at your code on Github and know what the code is doing. There is not enough information there. Contrast that with nominal type systems where everything I need to know about a function is right there. I don't need an IDE or external tooling to guide me. It's a true mystery how people think they are reviewing pull requests written in TypeScript and actually doing their job correctly. If you so much as have a single @ts-ignore or "any" in your code base, then all bets are off on correct behavior. TypeScript diminishes the point of type systems by giving the developer too many escape hatches. You ever see a developer abuse the non-null assertion operator in a case where it's not at all true that the value is not null, but the developer doesn't care because they just want to make the compiler happy? Yeah. I have. Then you have to explain the purpose of the non-null assertion operator and that goes about as well as you can imagine. If a type system isn't helping you understand your code or organize your code, then it's all rather pointless. TypeScript is incredibly complex. How many people using TypeScript can tell you something as basic as the difference between "interface" and "type"? And try to describe the difference without using sentences such as "well, originally..." and "back in 2017...". edit: Oh, and in case anyone thinks I'm being pedantic on that last point, check out this absolute shit show: https://stackoverflow.com/questions/37233735/interfaces-vs-types https://stackoverflow.com/questions/37233735/interfaces-vs-t... Keep scrolling down for ultimate depression.