3 ms·

Null is probably a bigger mistake.

by _alex_ 6y ago

bentaber 6y ago
Or smaller
- falcolas 6y ago
  Can’t tell, no data found...
kmonsen 6y ago
I think the problem is more that null exists but we like to simplify and pretend it doesn't most of the time. Null is just an extra state that can be useful, but sometimes it is so uncommon that we pretend that state is not there. Back when C programming was more prevalent I don't think null was that big an issue because most programmers were aware of it and would check for it. On second thought, the other big issue with null is that in many languages it just crashes the program which is a rather severe consequence you don't see for most mistakes.
blackrock 6y ago
Why is this? Sometimes, you do want to indicate that nothing came back. Python has the concept of None, which seems to function this way. You must check if the return type is None, and react appropriately.
- hn_throwaway_99 6y ago
  Null is not a problem with programming languages that correctly support (and enforce) optionals. The problem with null in, say, Java is that any object reference can potentially be null, which makes it very difficult to know when and why you should verify that something is non-null.
  - blackrock 6y ago
    This is the key. Didn’t Go or Rust figure this out correctly?
    - hn_throwaway_99 6y ago
      Lots of languages have since figured it out. Kotlin (which runs on the JVM) handles it well, https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html, as does Swift.
- ufo 6y ago
  It's a more obvious problem in typed languages like C or Java, where the type system can't help much to protect you against null pointer exceptions if you forget to check for null. Specially in C, where the null pointer exceptions cause billions of dollars of damage in the form of segfaults and nasal demons. In a language like Python the possibility that variables may contain values of different type (such as the None value) is part of the game. An inherent tradeoff of being dynamically typed.
- hydroxideOH- 6y ago
  In Racket and Scheme, false is the only 'falsy' value, with everything else evaluating 'truthy', which is nice since you don't have to worry about the specifics of the return type. I think the bigger issue with null or None, though, is not necessarily using it as a return type (where that makes sense, and can be enforced by a type system) but when objects are mutated to the value of null. The bigger issue there is with mutation and side-effects, but having null there as a convenient short cut can be a foot gun that leads to lots of errors.
deleted 6y ago
[deleted]

Null is probably a bigger mistake.

by _alex_ 6y ago

Null is probably a bigger mistake.

bentaber 6y ago

Or smaller

falcolas 6y ago
Can’t tell, no data found...

kmonsen 6y ago

I think the problem is more that null exists but we like to simplify and pretend it doesn't most of the time. Null is just an extra state that can be useful, but sometimes it is so uncommon that we pretend that state is not there. Back when C programming was more prevalent I don't think null was that big an issue because most programmers were aware of it and would check for it. On second thought, the other big issue with null is that in many languages it just crashes the program which is a rather severe consequence you don't see for most mistakes.

blackrock 6y ago

Why is this? Sometimes, you do want to indicate that nothing came back. Python has the concept of None, which seems to function this way. You must check if the return type is None, and react appropriately.

hn_throwaway_99 6y ago
Null is not a problem with programming languages that correctly support (and enforce) optionals. The problem with null in, say, Java is that any object reference can potentially be null, which makes it very difficult to know when and why you should verify that something is non-null.
- blackrock 6y ago
  This is the key. Didn’t Go or Rust figure this out correctly?
  - hn_throwaway_99 6y ago
    Lots of languages have since figured it out. Kotlin (which runs on the JVM) handles it well, https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html, as does Swift.
ufo 6y ago
It's a more obvious problem in typed languages like C or Java, where the type system can't help much to protect you against null pointer exceptions if you forget to check for null. Specially in C, where the null pointer exceptions cause billions of dollars of damage in the form of segfaults and nasal demons. In a language like Python the possibility that variables may contain values of different type (such as the None value) is part of the game. An inherent tradeoff of being dynamically typed.
hydroxideOH- 6y ago
In Racket and Scheme, false is the only 'falsy' value, with everything else evaluating 'truthy', which is nice since you don't have to worry about the specifics of the return type. I think the bigger issue with null or None, though, is not necessarily using it as a return type (where that makes sense, and can be enforced by a type system) but when objects are mutated to the value of null. The bigger issue there is with mutation and side-effects, but having null there as a convenient short cut can be a foot gun that leads to lots of errors.

deleted 6y ago

[deleted]