5 ms·

This is an argument against strongly typed languages, not Typescript. You could do a similar thing in Java and C#. I don't know of any language that can stop s

This is an argument against strongly typed languages, not Typescript. You could do a similar thing in Java and C#. I don't know of any language that can stop someone from being a sloppy coder.

xxpor 6y ago
Java would absolutely stop you from returning a JSON object when you're supposed to return a Thing. You could cast it but you'd still get a ClassCastException. Now I haven't written JS or TS, so maybe I'm not understanding what you're saying?
- damagednoob 6y ago
  Just like Generics in Java, Typescript only exists at compile time. Talking about what Typescript doesn't do at runtime is moot.
  - lmm 6y ago
    Typescript permits you to write code that does implicit unsafe casts at runtime. Type-safe languages don't. Java Generics don't let you implicitly do unsafe casts[1]; erased generics mean the unsafe cast wouldn't necessarily fail visibly at runtime (though there are warnings and linters to alert you to that, and techniques to work around it), but it would enforce that it was explicit in the code (and you would then know to add extra test coverage etc.). [1] You can implicitly do unsafe casts using arrays, but arrays aren't really using generics, they're a special-case builtin.
- winrid 6y ago
  The example above is equivalent to gson.toJSON(string, Thing.class) It'll just return an empty Thing right? No ClassCastException.
qw3rty01 6y ago
It's actually the opposite. This would throw an exception in a strongly typed language. It would silently return the wrong thing in javascript because it's not strongly typed.
- damagednoob 6y ago
  The point of the argument is catching errors at compile-time. Typescript doesn't make (and can't make) any guarantees at runtime.
  - lhorie 6y ago
    In case it wasn't clear, that example compiles without error, whereas a more strict compiler would complain that a any is not a Thing, or some similar error. The code doesn't even throw runtime errors, but you wouldn't be able to tell something is wrong unless a) a request providing the json string actually responded with the error string in the example (an edge case that is very easy to overlook during regular development) and you managed to catch the problem in tests, or b) you specifically went digging into the file that defines getThing looking for the implicit any cast that the compiler didn't tell you about or c) there's a compiler update that turns that any cast into an error What others are saying is that Java and friends do c) (throw compilation errors when implicitly casting between incompatible types)
ufmace 6y ago
No, those languages actually enforce type checking at runtime. The libraries for parsing JS that support parsing into a custom type will blow up right there if the provided JSON cannot be parsed into the provided class, not 5 steps later when you try to use something from that class that isn't actually there.
- damagednoob 6y ago
  Typescript doesn't exist at runtime.

This is an argument against strongly typed languages, not Typescript. You could do a similar thing in Java and C#. I don't know of any language that can stop someone from being a sloppy coder.

xxpor 6y ago

Java would absolutely stop you from returning a JSON object when you're supposed to return a Thing. You could cast it but you'd still get a ClassCastException. Now I haven't written JS or TS, so maybe I'm not understanding what you're saying?

damagednoob 6y ago
Just like Generics in Java, Typescript only exists at compile time. Talking about what Typescript doesn't do at runtime is moot.
- lmm 6y ago
  Typescript permits you to write code that does implicit unsafe casts at runtime. Type-safe languages don't. Java Generics don't let you implicitly do unsafe casts[1]; erased generics mean the unsafe cast wouldn't necessarily fail visibly at runtime (though there are warnings and linters to alert you to that, and techniques to work around it), but it would enforce that it was explicit in the code (and you would then know to add extra test coverage etc.). [1] You can implicitly do unsafe casts using arrays, but arrays aren't really using generics, they're a special-case builtin.
winrid 6y ago
The example above is equivalent to gson.toJSON(string, Thing.class) It'll just return an empty Thing right? No ClassCastException.

qw3rty01 6y ago

It's actually the opposite. This would throw an exception in a strongly typed language. It would silently return the wrong thing in javascript because it's not strongly typed.

damagednoob 6y ago
The point of the argument is catching errors at compile-time. Typescript doesn't make (and can't make) any guarantees at runtime.
- lhorie 6y ago
  In case it wasn't clear, that example compiles without error, whereas a more strict compiler would complain that a any is not a Thing, or some similar error. The code doesn't even throw runtime errors, but you wouldn't be able to tell something is wrong unless a) a request providing the json string actually responded with the error string in the example (an edge case that is very easy to overlook during regular development) and you managed to catch the problem in tests, or b) you specifically went digging into the file that defines getThing looking for the implicit any cast that the compiler didn't tell you about or c) there's a compiler update that turns that any cast into an error What others are saying is that Java and friends do c) (throw compilation errors when implicitly casting between incompatible types)

ufmace 6y ago

No, those languages actually enforce type checking at runtime. The libraries for parsing JS that support parsing into a custom type will blow up right there if the provided JSON cannot be parsed into the provided class, not 5 steps later when you try to use something from that class that isn't actually there.

damagednoob 6y ago
Typescript doesn't exist at runtime.