3 ms·

> Either you have good discipline regarding types where you need it or you don't. And discipline in your coding extends to way more than just type errors. So an

> Either you have good discipline regarding types where you need it or you don't. And discipline in your coding extends to way more than just type errors. So anything encouraging to develop your discipline is a good thing. I think this is maybe the crux of the difference of opinion between static and dynamic afficianados. I don't want to have to be disciplined. I want to be able to offload as much of the thinking as I possibly can onto my tools. The reason this is necessary is that I'm human, and I only have a human level capacity to not screw things up. If everything is the responsibility of the programmer, then we are limited in our ability to build large complex systems, to the ability of the programmer to manage this complexity. The only way to transcend this human limitation is to put measures in place to prevent things from falling over when humans turn out to be human after all.

vidarh 8y ago
Those measures you want are tests. You need them just as much with statically typed systems, but it's often easier to tell yourself you don't. If you compare static code with poor test coverage with dynamic code with poor test coverage, the dynamic code is probably more likely to fail with a runtime error of some sort, but in my experience they're about as likely to fail to produce the intended result. Once you add proper tests, most type errors in the dynamic code tends to get caught without specifically testing for it. I used to make this argument too, until I actually spent some time writing Ruby, and none of my fears came to pass.
- tigershark 8y ago
  You don’t really need tests for everything. If you make the invalid state unrepresentable in the type system then, guess what? You don’t need to test for its validity and more importantly you are guaranteed that if it compiles it can’t ever reach an invalid state. This renders a whole class of tests unnecessary.
  - vidarh 8y ago
    While that is true, you still need to test to ensure that your representation matches reality, and in practice when you do that in systems written in dynamic languages you tend to cover most type issues implicitly. For that matter it's not that hard to write code to statically validate that arguments to a given method are checked against a set of types and that this set does not include a representation of invalid values. (E.g. I can "forcibly" wrap any method with checks). The reason the various libraries to do that haven't gained much traction is that they've rarely paid for themselves in reduced effort compared to higher level tests. I'm all for more static validation, but I just don't think we have suitable tooling yet to do it at a level that provides sufficient benefit.

vidarh 8y ago

Those measures you want are tests. You need them just as much with statically typed systems, but it's often easier to tell yourself you don't. If you compare static code with poor test coverage with dynamic code with poor test coverage, the dynamic code is probably more likely to fail with a runtime error of some sort, but in my experience they're about as likely to fail to produce the intended result. Once you add proper tests, most type errors in the dynamic code tends to get caught without specifically testing for it. I used to make this argument too, until I actually spent some time writing Ruby, and none of my fears came to pass.

tigershark 8y ago
You don’t really need tests for everything. If you make the invalid state unrepresentable in the type system then, guess what? You don’t need to test for its validity and more importantly you are guaranteed that if it compiles it can’t ever reach an invalid state. This renders a whole class of tests unnecessary.
- vidarh 8y ago
  While that is true, you still need to test to ensure that your representation matches reality, and in practice when you do that in systems written in dynamic languages you tend to cover most type issues implicitly. For that matter it's not that hard to write code to statically validate that arguments to a given method are checked against a set of types and that this set does not include a representation of invalid values. (E.g. I can "forcibly" wrap any method with checks). The reason the various libraries to do that haven't gained much traction is that they've rarely paid for themselves in reduced effort compared to higher level tests. I'm all for more static validation, but I just don't think we have suitable tooling yet to do it at a level that provides sufficient benefit.