5 ms·

I've often speculated that strong typing only seems like a win to the kind of developer who makes a lot of type errors, and a waste of time to those who don't (

I've often speculated that strong typing only seems like a win to the kind of developer who makes a lot of type errors, and a waste of time to those who don't (which doesn't mean they don't make other errors, of course).

Aldo_MX 5y ago
Or to the kind of developer that works in a big team for a big project.
markstos 5y ago
Even developers who "don't make type errors" have to deal with bad and unexpected data, which may be in a different type. If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result. Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster. "Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types. My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript. Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"
rattlesnakedave 5y ago
bringing in tooling to eliminate an entire class of potential errors sounds sounds like an easy decision to me.
- Turing_Machine 5y ago
  Not if the errors are rare and the "tooling" slows down development.
  - frosted-flakes 5y ago
    Why do you think it would slow down development? Serious question.
    - scns 5y ago
      I was shocked how slow tsc is. Got spoiled by using ReasonML before.
    - Turing_Machine 5y ago
      Those type annotations don't just magically appear. You have to write them. Yeah, they're optional, but if you don't write them, there's no point in using TypeScript in the first place.
      - jeremyjh 5y ago
        Types are inferred even when you don't specify them; if you are using a library that has type specifications a lot of your code is going to be well-typed just as a consequence of using that library.
        Turing_Machine 5y ago
        1) "Someone else wrote them" doesn't make them free. Given a limited amount of developer time, that means that the time spent on the annotations wasn't spent on other functionality. 2) If the types can be inferred, that should just happen. No objection there. But this piece is specifically about "adding (manually-authored) type annotations to JavaScript"
  - moron4hire 5y ago
    Huh? Rebundling my 150kloc project takes about 2 seconds after I save a file and has already reloaded by the time I get to my browser window.
balefrost 5y ago
Alternatively, perhaps advocates of static typing simply see a larger variety of errors as type errors. In JS, if I typo a key of an object (e.g. `foo.excute()` instead of `foo.execute()`), I would call that a type error... or at least an error that could be caught by a static type system.
david422 5y ago
> like a win to the kind of developer who makes a lot of type errors Or just to the developer that likes to offload that cognitive load to their tools. Why hold that in my head when the IDE can keep track of it for me? Why memorize every single attribute name when the IDE can autocomplete it for me? etc.
- Turing_Machine 5y ago
  This is about manually-written type annotations. About as far as can be from "the IDE keeping track of it for you".
  - david422 5y ago
    You manually write the type annotation, and then the IDE keeps track of the rest. Instead keeping track of the type annotation in your head, and then also keeping track of the rest of the stuff in your head too.
jeremyjh 5y ago
I’ve speculated that a lot of developers don’t recognize type errors for what they are.

Aldo_MX 5y ago

Or to the kind of developer that works in a big team for a big project.

markstos 5y ago

Even developers who "don't make type errors" have to deal with bad and unexpected data, which may be in a different type. If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result. Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster. "Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types. My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript. Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"

rattlesnakedave 5y ago

bringing in tooling to eliminate an entire class of potential errors sounds sounds like an easy decision to me.

Turing_Machine 5y ago
Not if the errors are rare and the "tooling" slows down development.
- frosted-flakes 5y ago
  Why do you think it would slow down development? Serious question.
  - scns 5y ago
    I was shocked how slow tsc is. Got spoiled by using ReasonML before.
  - Turing_Machine 5y ago
    Those type annotations don't just magically appear. You have to write them. Yeah, they're optional, but if you don't write them, there's no point in using TypeScript in the first place.
    - jeremyjh 5y ago
      Types are inferred even when you don't specify them; if you are using a library that has type specifications a lot of your code is going to be well-typed just as a consequence of using that library.
      - Turing_Machine 5y ago
        1) "Someone else wrote them" doesn't make them free. Given a limited amount of developer time, that means that the time spent on the annotations wasn't spent on other functionality. 2) If the types can be inferred, that should just happen. No objection there. But this piece is specifically about "adding (manually-authored) type annotations to JavaScript"
- moron4hire 5y ago
  Huh? Rebundling my 150kloc project takes about 2 seconds after I save a file and has already reloaded by the time I get to my browser window.

balefrost 5y ago

Alternatively, perhaps advocates of static typing simply see a larger variety of errors as type errors. In JS, if I typo a key of an object (e.g. `foo.excute()` instead of `foo.execute()`), I would call that a type error... or at least an error that could be caught by a static type system.

david422 5y ago

> like a win to the kind of developer who makes a lot of type errors Or just to the developer that likes to offload that cognitive load to their tools. Why hold that in my head when the IDE can keep track of it for me? Why memorize every single attribute name when the IDE can autocomplete it for me? etc.

Turing_Machine 5y ago
This is about manually-written type annotations. About as far as can be from "the IDE keeping track of it for you".
- david422 5y ago
  You manually write the type annotation, and then the IDE keeps track of the rest. Instead keeping track of the type annotation in your head, and then also keeping track of the rest of the stuff in your head too.

jeremyjh 5y ago

I’ve speculated that a lot of developers don’t recognize type errors for what they are.