6 ms·

I think it’s the wrong metric to look at. Static typing still leaves plenty of room for bugs. The capability and discipline of the team would likely be more

I think it’s the wrong metric to look at. Static typing still leaves plenty of room for bugs. The capability and discipline of the team would likely be more of a factor than the type system so the studies would be hard to get right. However I do think static typing provides an enormous benefit to picking up code that is 5 years old and written by someone else. The ability to see “this is a nonnullable int32 value type” greatly reduces the amount of paths you have to go down when you have to change something or understand what’s going wrong with it. Tradeoff is you end up with a lot more code to maintain...

quonn 6y ago
It helps a lot with refactoring and many other things even early in the project. For example I‘m using TypeScript with a GraphQL code generator. Now let‘s assume I add a new value to a GraphQL enum. I run codegen, then fix everything until the compiler is happy. Afterwards, all places where this enum was ever touched will take it into account correctly, including mappings, translations, all switch statements, conditions, lists where some of the other values are mentioned and so on. This is something that‘s not possible in a dynamic language and it‘s not even possible in Java, really. I rely on this daily.
- archarios 6y ago
  You could do the same process if you used dynamic typing and good test coverage. Just make your change and keep fixing tests until everything is green.
  - wtetzner 6y ago
    But how could you have written tests against that new enum value if it didn't exist before? You would need to know in advance which places needed to be tested for it.
  - Ar-Curunir 6y ago
    Then you essentially are implementing a type checker in your tests, but worse
pavel_lishin 6y ago
I would change that "5 years" to "5 months" (or maybe even 5 weeks), and argue that you can just as easily be that "someone else" on a long enough time-scale (and I don't mean 5 years.)
- dahauns 6y ago
  That hits closer to home than I'd like to admit. :)

quonn 6y ago

It helps a lot with refactoring and many other things even early in the project. For example I‘m using TypeScript with a GraphQL code generator. Now let‘s assume I add a new value to a GraphQL enum. I run codegen, then fix everything until the compiler is happy. Afterwards, all places where this enum was ever touched will take it into account correctly, including mappings, translations, all switch statements, conditions, lists where some of the other values are mentioned and so on. This is something that‘s not possible in a dynamic language and it‘s not even possible in Java, really. I rely on this daily.

archarios 6y ago
You could do the same process if you used dynamic typing and good test coverage. Just make your change and keep fixing tests until everything is green.
- wtetzner 6y ago
  But how could you have written tests against that new enum value if it didn't exist before? You would need to know in advance which places needed to be tested for it.
- Ar-Curunir 6y ago
  Then you essentially are implementing a type checker in your tests, but worse

pavel_lishin 6y ago

I would change that "5 years" to "5 months" (or maybe even 5 weeks), and argue that you can just as easily be that "someone else" on a long enough time-scale (and I don't mean 5 years.)

dahauns 6y ago
That hits closer to home than I'd like to admit. :)