4 ms·

In my opinion, "1" + 1 should throw an error, the compiler shouldn't try to interpret what you meant. Dynamic typing opens you up to all sorts of bugs that don'

In my opinion, "1" + 1 should throw an error, the compiler shouldn't try to interpret what you meant. Dynamic typing opens you up to all sorts of bugs that don't happen with static. That being said, I don't think dynamic typing is going anywhere, and with experience it's not that difficult to anticipate the problems that come with dynamic typing.

deleted 8y ago
[deleted]
vinceguidry 8y ago
It really isn't all that difficult. Coercion works fine for the case you cited, and especially Ruby has specific idiomatic coercion methods with the semantics you'd want. Ruby does in fact throw a TypeError when you call "1" + 1. The issue is that static typing purists want that error to be thrown at compile time. I don't see that as necessary. 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 what it comes down to is, not having dynamic typing available to me when I want it is going to be more painful overall than not having a type system when I want it. I look at all the static languages today and I see so much validation of this idea that it's not even funny.
- sullyj3 8y ago
  > 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.
out_of_protocol 8y ago
You are mixing weak and dynamic typing together. Weak, as in JavaScript, PHP, does allow "1"+1 stuff and should be burned with fire. Dynamic strong typing, as in Python, Ruby, does not allow such stuff (though can not be catched at compile time)

deleted 8y ago

[deleted]

vinceguidry 8y ago

It really isn't all that difficult. Coercion works fine for the case you cited, and especially Ruby has specific idiomatic coercion methods with the semantics you'd want. Ruby does in fact throw a TypeError when you call "1" + 1. The issue is that static typing purists want that error to be thrown at compile time. I don't see that as necessary. 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 what it comes down to is, not having dynamic typing available to me when I want it is going to be more painful overall than not having a type system when I want it. I look at all the static languages today and I see so much validation of this idea that it's not even funny.

sullyj3 8y ago
> 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.

out_of_protocol 8y ago

You are mixing weak and dynamic typing together. Weak, as in JavaScript, PHP, does allow "1"+1 stuff and should be burned with fire. Dynamic strong typing, as in Python, Ruby, does not allow such stuff (though can not be catched at compile time)