3 ms·

It is not evident to me. Having used both statically typed and dynamically typed languages my experience is that I can't remember ever seeing a bug in our fairl

It is not evident to me. Having used both statically typed and dynamically typed languages my experience is that I can't remember ever seeing a bug in our fairly large rails app that a type system would catch. Nobody's passing strings where hashes are expected, or Widget instances where User instances are expected. The thing to pass to the function is nearly always self evident. If you did it would immediately be caught when a test runs anyway. However, refactoring code in C# is much easier than refactoring ruby because you can lean on the type system there. However writing new code in C# is often much harder to do in C# because of the constraints of the type system. So really, it ends up being a wash for me.

unethical_ban 4y ago
>Nobody's passing strings where hashes are expected See, When I'm throwing together apps to clean up configurations, I am Pythonifying XML often. And when handling different return values, reshaping it into the useful components I need and trying to analyze data (and dealing with different return formats depending on number of results, aka a dict if there is one value, or a list(dict) if there are more) I have to constantly remember if I am going to be getting a list(dict(dict(dict(str)))) or just a dict(dict(string)), and so on. But that's me cobbling together scripts and not understanding the API by heart well enough.
imiric 4y ago
> If you did it would immediately be caught when a test runs anyway. That's the point though. With dynamic typing you would only (hopefully) catch this with manually written tests. With static typing you get that feedback for free at build time.
- tene 4y ago
  With static types, every function signature implicitly comes with built-in tests for free.
  - jacobsenscott 4y ago
    Not true because anyone can implement just part of an interface and throw "method undefined" for the methods they can't figure out how to implement. This happens all the time.
    - KptMarchewa 4y ago
      > Not true because anyone can implement just part of an interface and throw "method undefined" for the methods they can't figure out how to implement. This happens all the time. How would that pass any code review, regardless of static or dynamic typing?
    - tene 4y ago
      The only time I have ever seen something like this is using `todo!()` while initially writing code. I have never seen someone check in code like this. What kind of clown show of a programming org are you working at? This is morally equivalent to "There's no point to having a safety on a gun, because the safety won't stop you from bashing someone in the face with the gun." If you really want to, you can throw exceptions or crash the process or call exit() or call system("shutdown -h now") anywhere in your codebase. That has nothing to do with a type system.
- KptMarchewa 4y ago
  Even faster, at "type time" if you use any decent IDE.
devit 4y ago
Even trivial things like a typo in the method name in a method call are not detected at compile time by languages like JavaScript or Ruby (since their "method calls" are in fact just lookups in a runtime hash table...). If you have not seen them, the reason is probably that the code was tested well enough before you looked for the bugs.
semiquaver 4y ago
If you search your exception tracker for NoMethodError in production, do any results come up?
- jacobsenscott 4y ago
  Yes - in every case it is calling a method on a null reference. And no commonly used statically typed language helps here because they all allow null references. And languages that disallow nulls, if you are one of the 10 programmers on earth working in one of those languages, don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway.
  - ylyn 4y ago
    > don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway. You clearly have little experience with such languages, then.
  - Too 4y ago
    Python (with mypy) has strict optional on as default and is the most widely used language, according to the latest stackoverflow ranking. Assuming you use mypy of course, which probably takes the usage rate down a factor of 100x but still.. ;) It makes you actually have to consider scenarios where a variable can be none or not and try to push the validation up closer to where it entered the system.
  - tene 4y ago
    > no commonly used statically typed language helps here because they all allow null references This is false. TypeScript, Swift, and Rust are commonly used and support non-nullable references. > those languages, don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway. You don't need escape hatches to deal with "real world data" that may be missing some values. This blog post is my favorite detailed comparison of handling "real world data" in static vs dynamic languages: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ... Rust's serde_json docs on "Operating on untyped JSON values" are also a pretty good description of working with "real world data" where you want to examine an arbitrary document: https://docs.serde.rs/serde_json/#operating-on-untyped-json-values https://docs.serde.rs/serde_json/#operating-on-untyped-json-... The only requirement for working with "real world data" in a static non-nullable language is to choose whatever kind of behaviour you want when working with the data. Everything you can do with null references, you can do better with option types; there is nothing that null references uniquely permit.
tene 4y ago
Have you ever had crashes caused by unexpected use of nil/null/undefined? Using the return value from a function without checking for errors?

unethical_ban 4y ago

>Nobody's passing strings where hashes are expected See, When I'm throwing together apps to clean up configurations, I am Pythonifying XML often. And when handling different return values, reshaping it into the useful components I need and trying to analyze data (and dealing with different return formats depending on number of results, aka a dict if there is one value, or a list(dict) if there are more) I have to constantly remember if I am going to be getting a list(dict(dict(dict(str)))) or just a dict(dict(string)), and so on. But that's me cobbling together scripts and not understanding the API by heart well enough.

imiric 4y ago

> If you did it would immediately be caught when a test runs anyway. That's the point though. With dynamic typing you would only (hopefully) catch this with manually written tests. With static typing you get that feedback for free at build time.

tene 4y ago
With static types, every function signature implicitly comes with built-in tests for free.
- jacobsenscott 4y ago
  Not true because anyone can implement just part of an interface and throw "method undefined" for the methods they can't figure out how to implement. This happens all the time.
  - KptMarchewa 4y ago
    > Not true because anyone can implement just part of an interface and throw "method undefined" for the methods they can't figure out how to implement. This happens all the time. How would that pass any code review, regardless of static or dynamic typing?
  - tene 4y ago
    The only time I have ever seen something like this is using `todo!()` while initially writing code. I have never seen someone check in code like this. What kind of clown show of a programming org are you working at? This is morally equivalent to "There's no point to having a safety on a gun, because the safety won't stop you from bashing someone in the face with the gun." If you really want to, you can throw exceptions or crash the process or call exit() or call system("shutdown -h now") anywhere in your codebase. That has nothing to do with a type system.
KptMarchewa 4y ago
Even faster, at "type time" if you use any decent IDE.

devit 4y ago

Even trivial things like a typo in the method name in a method call are not detected at compile time by languages like JavaScript or Ruby (since their "method calls" are in fact just lookups in a runtime hash table...). If you have not seen them, the reason is probably that the code was tested well enough before you looked for the bugs.

semiquaver 4y ago

If you search your exception tracker for NoMethodError in production, do any results come up?

jacobsenscott 4y ago
Yes - in every case it is calling a method on a null reference. And no commonly used statically typed language helps here because they all allow null references. And languages that disallow nulls, if you are one of the 10 programmers on earth working in one of those languages, don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway.
- ylyn 4y ago
  > don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway. You clearly have little experience with such languages, then.
- Too 4y ago
  Python (with mypy) has strict optional on as default and is the most widely used language, according to the latest stackoverflow ranking. Assuming you use mypy of course, which probably takes the usage rate down a factor of 100x but still.. ;) It makes you actually have to consider scenarios where a variable can be none or not and try to push the validation up closer to where it entered the system.
- tene 4y ago
  > no commonly used statically typed language helps here because they all allow null references This is false. TypeScript, Swift, and Rust are commonly used and support non-nullable references. > those languages, don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway. You don't need escape hatches to deal with "real world data" that may be missing some values. This blog post is my favorite detailed comparison of handling "real world data" in static vs dynamic languages: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ... Rust's serde_json docs on "Operating on untyped JSON values" are also a pretty good description of working with "real world data" where you want to examine an arbitrary document: https://docs.serde.rs/serde_json/#operating-on-untyped-json-values https://docs.serde.rs/serde_json/#operating-on-untyped-json-... The only requirement for working with "real world data" in a static non-nullable language is to choose whatever kind of behaviour you want when working with the data. Everything you can do with null references, you can do better with option types; there is nothing that null references uniquely permit.

tene 4y ago

Have you ever had crashes caused by unexpected use of nil/null/undefined? Using the return value from a function without checking for errors?