9 ms·

The vast majority of people using TypeScript in their projects won't run into the deeper complexity of the type system. For the average TS user the only visible

The vast majority of people using TypeScript in their projects won't run into the deeper complexity of the type system. For the average TS user the only visible impact of features like template literal types and recursive conditional types will be fewer bugs because maintainers of popular libraries used them to provide better types. You don't have to personally understand TS's more complicated features to benefit from using TS in your project. I hope they continue adding richness to the type system so I can eliminate more bugs from my code.

commentrix 6y ago
Excellent pro TS propaganda, and apologism for exploding complexity. I love the idea of type checking, but the implementation of it seems buggy. tsc checkJS will make incorrect type inferences and throw errors about situations that won't happen, and it does this inconsistently, seemingly dependent on the syntax, for instance that a new promise's resolve function is possibly undefined.
lenkite 6y ago
Typescript is approaching C++ complexity since this is pretty much the same answer that people give when someone complains that C++ is very complex.
- root_axis 6y ago
  That seems like a pretty superficial connection.
- mb7733 6y ago
  How could typescript be approaching C++ complexity when it's just JS with types? The advanced typing features don't affect the semantics of programs. They just make the type system more expressive so more things can be validated by the compiler. In other words, typescript doesn't make the language any bigger. If you're struggling to understand typescript code you could just ignore the types, and you're back with regular JS. This is different than the issue some people have with a big language like C++, where the sheer number of features can make it hard to get a grip on unfamiliar codebases.
  - winstonewert 6y ago
    Well, for one thing, I want my code to pass typescripts type checker. So I can't just ignore the types and go back to regular javascript. I've got to understand the sometimes complicated static typing semantics
    - mb7733 6y ago
      The TS devs adding support for more advanced types in tsc doesn't make it any harder for your code to pass type checking. That just depends on (1) how strictly you have configured the type checker and (2) how specific you make your type definitions. The more advanced types just allow more specific type definitions. So if try to you them, and you can't get them to work... you can just avoid the advanced features and leave the type definitions more vague. Just like how if you can't get the basic types to work, you can always use "any".
      - winstonewert 6y ago
        And now you are changing your claim, showing, quite frankly, that I was right. Your original claim was bogus. Furthermore, your new claim is also nonsensical. The fact that I don't have to use all the advanced features of my languages doesn't alter the complexity of the language.
        mb7733 6y ago
        I'm not sure what you mean by my claims. I'm just saying there is a big difference between adding features to the language and adding features to the type system.
        winstonewert 6y ago
        You said "How could typescript be approaching C++ complexity when it's just JS with types?" The implication being an assertion that typescript cannot be getting as complicated as C++, and that's simply isn't true. Given that the type system is part of a language, I have no idea what you mean by trying to draw a big distinction between adding features to a language and a language's typesystem.
- lmm 6y ago
  That's like saying any country that talks about how democratic it is must be like the Soviet Union. Sometimes you have to actually look at the details behind the claims. There are specific problems with C++, and its features are often not orthogonal enough to use independently. That doesn't mean that it's impossible to add orthogonal features that don't complicate a language for people who don't use them, it only means that C++ has failed to.
holoduke 6y ago
Always when typescript is is compared with js, people talk about you get less bugs in typescript. I am honestly curious to see some evidence. In my opinion application bugs are usually in the flow itself and have nothing to do with wrong types. I work a lot with both plain and Typescript projects. I used to like Typescript. But not anymore. With typescript applications tend to become bigger and more complex. Most devs using it have never seen vanilla js and are more java minded that prototype minded. IDE code completion works better for typescript. For sure. But is that really essential? Sounds a bit like the typical Java developer who works with giant spring applications containing classes with hundreds of methods spread in many files in a 10 layer deep folder structure.
- timdaub 6y ago
  As someone that's extensively testing their application, I don't get the bug argument either. Sure some bugs are found during compile time. Actually, it's not bugs the compiler finds. Rather it's inconsitencies between types and the rest of the code. But when testing properly, these should anyways be found later. Or am I missing something?
  - egeozcan 6y ago
    It's a given that you can reduce the number of bugs in your app eventually, with any method/tool you can imagine, given enough time. That'd be still true if you were designing using sticks and stones on sand. Why not use another tool that helps you fix bugs easier, faster and sometimes spare you from writing them at all?
    - timdaub 6y ago
      Why so aggressive? I asked a simple question out of interest. Again, I think there's a difference between bug and a coding error. A bug is a mismatch between a software's function and the user's expectation. And a typed-inferred error during compile time is just a hint that some code is incorrect. It may lead to a bug, but at the point of compilation, it's not a bug.
motogpjimbo 6y ago
I've seen the same claim made about the more obscure features found in application frameworks, and in both cases the problem is the same: there will always be that one guy on your team who takes delight in finding a complicated and mentally burdensome solution to an otherwise simple problem, which requires everyone on the team to at least be aware that certain constructs exist. It's great that Typescript is catching on, and we're starting to adopt it in my team, but I hope the TS people don't think they can keep adding new features to it in perpetuity, otherwise it's going to turn into C++.

commentrix 6y ago

Excellent pro TS propaganda, and apologism for exploding complexity. I love the idea of type checking, but the implementation of it seems buggy. tsc checkJS will make incorrect type inferences and throw errors about situations that won't happen, and it does this inconsistently, seemingly dependent on the syntax, for instance that a new promise's resolve function is possibly undefined.

lenkite 6y ago

Typescript is approaching C++ complexity since this is pretty much the same answer that people give when someone complains that C++ is very complex.

root_axis 6y ago
That seems like a pretty superficial connection.
mb7733 6y ago
How could typescript be approaching C++ complexity when it's just JS with types? The advanced typing features don't affect the semantics of programs. They just make the type system more expressive so more things can be validated by the compiler. In other words, typescript doesn't make the language any bigger. If you're struggling to understand typescript code you could just ignore the types, and you're back with regular JS. This is different than the issue some people have with a big language like C++, where the sheer number of features can make it hard to get a grip on unfamiliar codebases.
- winstonewert 6y ago
  Well, for one thing, I want my code to pass typescripts type checker. So I can't just ignore the types and go back to regular javascript. I've got to understand the sometimes complicated static typing semantics
  - mb7733 6y ago
    The TS devs adding support for more advanced types in tsc doesn't make it any harder for your code to pass type checking. That just depends on (1) how strictly you have configured the type checker and (2) how specific you make your type definitions. The more advanced types just allow more specific type definitions. So if try to you them, and you can't get them to work... you can just avoid the advanced features and leave the type definitions more vague. Just like how if you can't get the basic types to work, you can always use "any".
    - winstonewert 6y ago
      And now you are changing your claim, showing, quite frankly, that I was right. Your original claim was bogus. Furthermore, your new claim is also nonsensical. The fact that I don't have to use all the advanced features of my languages doesn't alter the complexity of the language.
      - mb7733 6y ago
        I'm not sure what you mean by my claims. I'm just saying there is a big difference between adding features to the language and adding features to the type system.
        winstonewert 6y ago
        You said "How could typescript be approaching C++ complexity when it's just JS with types?" The implication being an assertion that typescript cannot be getting as complicated as C++, and that's simply isn't true. Given that the type system is part of a language, I have no idea what you mean by trying to draw a big distinction between adding features to a language and a language's typesystem.
lmm 6y ago
That's like saying any country that talks about how democratic it is must be like the Soviet Union. Sometimes you have to actually look at the details behind the claims. There are specific problems with C++, and its features are often not orthogonal enough to use independently. That doesn't mean that it's impossible to add orthogonal features that don't complicate a language for people who don't use them, it only means that C++ has failed to.

holoduke 6y ago

Always when typescript is is compared with js, people talk about you get less bugs in typescript. I am honestly curious to see some evidence. In my opinion application bugs are usually in the flow itself and have nothing to do with wrong types. I work a lot with both plain and Typescript projects. I used to like Typescript. But not anymore. With typescript applications tend to become bigger and more complex. Most devs using it have never seen vanilla js and are more java minded that prototype minded. IDE code completion works better for typescript. For sure. But is that really essential? Sounds a bit like the typical Java developer who works with giant spring applications containing classes with hundreds of methods spread in many files in a 10 layer deep folder structure.

timdaub 6y ago
As someone that's extensively testing their application, I don't get the bug argument either. Sure some bugs are found during compile time. Actually, it's not bugs the compiler finds. Rather it's inconsitencies between types and the rest of the code. But when testing properly, these should anyways be found later. Or am I missing something?
- egeozcan 6y ago
  It's a given that you can reduce the number of bugs in your app eventually, with any method/tool you can imagine, given enough time. That'd be still true if you were designing using sticks and stones on sand. Why not use another tool that helps you fix bugs easier, faster and sometimes spare you from writing them at all?
  - timdaub 6y ago
    Why so aggressive? I asked a simple question out of interest. Again, I think there's a difference between bug and a coding error. A bug is a mismatch between a software's function and the user's expectation. And a typed-inferred error during compile time is just a hint that some code is incorrect. It may lead to a bug, but at the point of compilation, it's not a bug.

motogpjimbo 6y ago

I've seen the same claim made about the more obscure features found in application frameworks, and in both cases the problem is the same: there will always be that one guy on your team who takes delight in finding a complicated and mentally burdensome solution to an otherwise simple problem, which requires everyone on the team to at least be aware that certain constructs exist. It's great that Typescript is catching on, and we're starting to adopt it in my team, but I hope the TS people don't think they can keep adding new features to it in perpetuity, otherwise it's going to turn into C++.