5 ms·

The article mentions the literature review is from 2014. Many older statically typed languages (Java/C/etc.) don’t enforce null safety. Tony Hoare called it hi

The article mentions the literature review is from 2014. Many older statically typed languages (Java/C/etc.) don’t enforce null safety. Tony Hoare called it his ‘billion dollar mistake’. https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retra... Thankfully more modern type systems (Swift/Kotlin/F#/Rust/TypeScript/etc.) now do, hugely reducing the likelihood of runtime errors. As a mostly dynamic language developer I never saw the benefit of Java-like static typing but more modern type systems seem much more useful.

chrisseaton 4y ago
> hugely reducing the likelihood of runtime errors You say this like it's a fact... but again nobody has been able to show this in a proper scientific study.
- slaymaker1907 4y ago
  Considering how many null pointer bugs I've seen, I think that this is a case where absence of evidence is not evidence of absence (at least for null safety).
  - chrisseaton 4y ago
    There's no evidence of the absence of the easter bunny, but we are happy that he probably doesn't exist since there's an absence of evidence. Write up your experience with null safety as a paper and submit it, because this would be a world-first if you can demonstrate it.
    - wtetzner 4y ago
      I’m not really sure what you’re arguing. You seem to be saying that since we can’t prove that one approach is better than the other, we should just assume they’re all equal. We do have proofs that certain classes of bugs are impossible given a certain type system.
  - BlargMcLarg 4y ago
    Almost all of the null pointer errors I've seen came from not fully thinking things through. I can see the same mistakes happening with non-nullable types because someone got lazy and passed a default value or something. You get the benefit of the compiler shouting at you for not initializing a variable, but that won't necessarily protect you from not thinking every situation through / lazily passing default values / making poor assumptions. I'm with GP, I'd really like evidence of this before people continue shouting things which aren't proven.
    - ReactiveJelly 4y ago
      But the languages that are null-safe all have Option, Optional or Maybe. So if I do need a null value, I can make the field optional and the type checker will help me figure it all out.
- tasuki 4y ago
  I don't think a scientific study is needed. There exist different classes of bugs. The stronger static typing, the more classes of bugs become impossible to make. You will not see a NullPointerException in Haskell. The only way in which strong static and dynamic typing could produce the same number of bugs would be if strong static typing resulted in introducing other bugs, ones which wouldn't be introduced in a dynamically typed language. Proving that would probably require a scientific study ;)
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]

chrisseaton 4y ago

> hugely reducing the likelihood of runtime errors You say this like it's a fact... but again nobody has been able to show this in a proper scientific study.

slaymaker1907 4y ago
Considering how many null pointer bugs I've seen, I think that this is a case where absence of evidence is not evidence of absence (at least for null safety).
- chrisseaton 4y ago
  There's no evidence of the absence of the easter bunny, but we are happy that he probably doesn't exist since there's an absence of evidence. Write up your experience with null safety as a paper and submit it, because this would be a world-first if you can demonstrate it.
  - wtetzner 4y ago
    I’m not really sure what you’re arguing. You seem to be saying that since we can’t prove that one approach is better than the other, we should just assume they’re all equal. We do have proofs that certain classes of bugs are impossible given a certain type system.
- BlargMcLarg 4y ago
  Almost all of the null pointer errors I've seen came from not fully thinking things through. I can see the same mistakes happening with non-nullable types because someone got lazy and passed a default value or something. You get the benefit of the compiler shouting at you for not initializing a variable, but that won't necessarily protect you from not thinking every situation through / lazily passing default values / making poor assumptions. I'm with GP, I'd really like evidence of this before people continue shouting things which aren't proven.
  - ReactiveJelly 4y ago
    But the languages that are null-safe all have Option, Optional or Maybe. So if I do need a null value, I can make the field optional and the type checker will help me figure it all out.
tasuki 4y ago
I don't think a scientific study is needed. There exist different classes of bugs. The stronger static typing, the more classes of bugs become impossible to make. You will not see a NullPointerException in Haskell. The only way in which strong static and dynamic typing could produce the same number of bugs would be if strong static typing resulted in introducing other bugs, ones which wouldn't be introduced in a dynamically typed language. Proving that would probably require a scientific study ;)
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]