5 ms·

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 v

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.
    - resonantjacket5 6y ago
      yeah I agree it is kinda confusing. types and interfaces used to be more separate but now they're kinda converging where its confusing when to use which. I don't think typescript can ever be too strict, there's lots of other regular javascript files and libraries typescript will need to interact with. True it gives you plenty of escape hatches, but the point is to have less escape hatches than javascript. Your team can discuss what should or shouldn't be allowed, I'm not sure how having strict typescript is really solving the problem of mis-aligned expectations for what is allowed code. Regarding the non-null behavior I've found that the real problem usually isn't with the variable's type definition but with it being a 'global' or not properly defined with the constructor. One can't define it as non-null because they don't know when it is constructed aka they add a property to a class that they plan on adding later when they should probably either fetch that property first or ensure it is done in the constructor. To be slightly fair you do get similar stuff in say java where interfaces slowly gained default methods and got closer to abstract classes.
    - jdxcode 6y ago
      > If you so much as have a single @ts-ignore or "any" in your code base, then all bets are off on correct behavior. I've been writing a ton of TS since 2016 and in most of those projects we've had liberal use of 'any' or even incorrect types (!). It's still far better than vanilla JS. The argument that "it doesn't work all the time therefore it's worse" makes no sense to me. Ultimately the issues you're talking about make logical sense academically, but nobody has ever raised them as problems in the real world that I've ever encountered. Full typing makes my job easy, but a little bit of typing is still better (in most cases) than no typing at all. There is an argument to be made about simplicity for small codebases, but those aren't the ones I'm talking about.
btbuildem 6y ago
Color | undefined; tells me that the dev who wrote the code doesn't know whether they will pass the parameter or not, it gets decided at runtime. Not only does this complicate the function signature, it inevitably adds a conditional inside that method -- or passes the buck down the line to another method called from within. At that point, TS is just a burden.

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.
  - resonantjacket5 6y ago
    yeah I agree it is kinda confusing. types and interfaces used to be more separate but now they're kinda converging where its confusing when to use which. I don't think typescript can ever be too strict, there's lots of other regular javascript files and libraries typescript will need to interact with. True it gives you plenty of escape hatches, but the point is to have less escape hatches than javascript. Your team can discuss what should or shouldn't be allowed, I'm not sure how having strict typescript is really solving the problem of mis-aligned expectations for what is allowed code. Regarding the non-null behavior I've found that the real problem usually isn't with the variable's type definition but with it being a 'global' or not properly defined with the constructor. One can't define it as non-null because they don't know when it is constructed aka they add a property to a class that they plan on adding later when they should probably either fetch that property first or ensure it is done in the constructor. To be slightly fair you do get similar stuff in say java where interfaces slowly gained default methods and got closer to abstract classes.
  - jdxcode 6y ago
    > If you so much as have a single @ts-ignore or "any" in your code base, then all bets are off on correct behavior. I've been writing a ton of TS since 2016 and in most of those projects we've had liberal use of 'any' or even incorrect types (!). It's still far better than vanilla JS. The argument that "it doesn't work all the time therefore it's worse" makes no sense to me. Ultimately the issues you're talking about make logical sense academically, but nobody has ever raised them as problems in the real world that I've ever encountered. Full typing makes my job easy, but a little bit of typing is still better (in most cases) than no typing at all. There is an argument to be made about simplicity for small codebases, but those aren't the ones I'm talking about.

btbuildem 6y ago

Color | undefined; tells me that the dev who wrote the code doesn't know whether they will pass the parameter or not, it gets decided at runtime. Not only does this complicate the function signature, it inevitably adds a conditional inside that method -- or passes the buck down the line to another method called from within. At that point, TS is just a burden.