4 ms·

The biggest problem the parent comment have with JS is not types, as you say, but a lack of a static type system. They are things as different as that you

The biggest problem the parent comment have with JS is not types, as you say, but __a lack of a static type system__. They are things as different as that you can actually have type problems only in a really typed system (as a static type system). Javascript has a very weak type system, and that's the problem. I think you do not understand that static typing serves to solve other problems in the code, not to solve type problems ... it would be like saying that an hypothetical language needs functions to solve function problems ... and then you say that you never had problems with functions in that hypothetical language (ex: assembler, with very primitives "functions", where you have to save data in register before jumping to code in another memory address).

Zelphyr 7y ago
Having a static type system is great but it’s just another tool in the toolbox. I’ve been writing Javascript for 23 years without types and didn’t miss them. They’re great when I have them in other languages but not a deal killer in languages that I don’t. But so many TypeScript fans act as if having types is the be-all and end-all. And, unless I’m mistaken and something has changed recently, I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking since the compiler strips away the types after TypeScript gets compiled down to Javascript. Don’t get me wrong; TypeScript is great. But I don’t see it as the savior that others make it out to be.
- rgoulter 7y ago
  "I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking" Surely the biggest benefit from static typing is for static-analysis tooling. (e.g. strong compile-time checks).
  - Zelphyr 7y ago
    I don’t disagree but the way people speak about static typing is as if it’s present during the life of the application.
    - quickthrower2 7y ago
      Different languages have different types of behaviour under the "static typing" umbrella. Typescript has chosen to interop nicely with JS, and they took the tradeoff that if you are passed an object (e.g. from an Ajax request) and you assert that it's a Duck, TS will assume that is correct during static typing. Of course this might be wrong at runtime, you may get returned {'foo':1} instead of {'foo':'bar'} and your object.foo.length now returns undefined. Static typing in general (in other languages) does persist into the lifetime of the application. By persist, I mean the guarantees persist, even if the types are thrown away. Haskell for example throws away the types at runtime (you can't reflect on them) but because it's so strict, you can be sure that X: String->String does indeed return a string. This you cannot be 100% sure of in Typescript. So why is Typescript useful? Well if you write an entire app in TS (which I am doing now) then all the code you write ... which is the new non-battle-tested code ... is now type checked against itself. Also well written libraries using TS will be well type checked against. People doing stuff like casting to <any> etc. could break things for you. But in general you get Pareto's rule applied and because most of your code is type checked (and it only isn't when getting stuff from the server or using a dodgy library that has exported an incorrect .d.ts or something), then you get almost 100% of the benefit. Basically am I getting errors due to incorrect types at runtime in Haskell? Never. Am I getting them in Typescript? Not yet but it's possible, maybe 0.1% chance?

The biggest problem the parent comment have with JS is not types, as you say, but __a lack of a static type system__. They are things as different as that you

Zelphyr 7y ago

Having a static type system is great but it’s just another tool in the toolbox. I’ve been writing Javascript for 23 years without types and didn’t miss them. They’re great when I have them in other languages but not a deal killer in languages that I don’t. But so many TypeScript fans act as if having types is the be-all and end-all. And, unless I’m mistaken and something has changed recently, I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking since the compiler strips away the types after TypeScript gets compiled down to Javascript. Don’t get me wrong; TypeScript is great. But I don’t see it as the savior that others make it out to be.

rgoulter 7y ago
"I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking" Surely the biggest benefit from static typing is for static-analysis tooling. (e.g. strong compile-time checks).
- Zelphyr 7y ago
  I don’t disagree but the way people speak about static typing is as if it’s present during the life of the application.
  - quickthrower2 7y ago
    Different languages have different types of behaviour under the "static typing" umbrella. Typescript has chosen to interop nicely with JS, and they took the tradeoff that if you are passed an object (e.g. from an Ajax request) and you assert that it's a Duck, TS will assume that is correct during static typing. Of course this might be wrong at runtime, you may get returned {'foo':1} instead of {'foo':'bar'} and your object.foo.length now returns undefined. Static typing in general (in other languages) does persist into the lifetime of the application. By persist, I mean the guarantees persist, even if the types are thrown away. Haskell for example throws away the types at runtime (you can't reflect on them) but because it's so strict, you can be sure that X: String->String does indeed return a string. This you cannot be 100% sure of in Typescript. So why is Typescript useful? Well if you write an entire app in TS (which I am doing now) then all the code you write ... which is the new non-battle-tested code ... is now type checked against itself. Also well written libraries using TS will be well type checked against. People doing stuff like casting to <any> etc. could break things for you. But in general you get Pareto's rule applied and because most of your code is type checked (and it only isn't when getting stuff from the server or using a dodgy library that has exported an incorrect .d.ts or something), then you get almost 100% of the benefit. Basically am I getting errors due to incorrect types at runtime in Haskell? Never. Am I getting them in Typescript? Not yet but it's possible, maybe 0.1% chance?