4 ms·

The problem is that you don't always have a legal state, especially at object creation. If you forbid illegal states you end up with fake objects taking the pl

The problem is that you don't always have a legal state, especially at object creation. If you forbid illegal states you end up with fake objects taking the place of non-existent real ones. (What's Find supposed to return if it's not there??) In most cases it's better to blow up when you try to work with a null than to mistakenly work with something that takes the place of a null. A null is easier to detect and thus the better solution. Yeah, well implemented nullable and not-nullable types are good but the compilers didn't have that kind of smarts in the old days.

lmm 4y ago
> If you forbid illegal states you end up with fake objects taking the place of non-existent real ones. You don't use a fake object, you use a real one of a different type. In the cases where what you want is "maybe this thing, maybe nothing" you can use an option/maybe type. In the cases where you want something else (e.g. "either this thing or an error message") you can use a type that represents that. > Yeah, well implemented nullable and not-nullable types are good but the compilers didn't have that kind of smarts in the old days. ML had well typed optionals back in the '70s. There's no excuse for using a language that needs null today.
- GoblinSlayer 4y ago
  In C++ std::optional<T>::value throws an std::bad_optional_access exception when the value is missing. How is this different from a NullPointerException?
  - lmm 4y ago
    > How is this different from a NullPointerException? It's different because most things can't throw it. The problem isn't that your language has a way to implement a value that might be absent, the problem is that your language does't have a way to implement a (heap) value that won't be absent, except by convention.
    - GoblinSlayer 4y ago
      If the value won't be absent, then it won't throw.
      - lmm 4y ago
        I'd like to know that the value won't be absent when I build the code rather than when I execute it.
pjmlp 4y ago
Easily solved by making an error to read before write, several languages do it.
- LorenPechtel 4y ago
  But that's runtime expensive, or else very restrictive on the compiler. Bad data should fail fast and null is good at doing that.
  - pjmlp 4y ago
    It is done at compile time. For example in C#, you would get something like "Use of unassigned local variable xyz". If the performance cost of initilizing the variable is such an unberable cost, there is [SkipLocalsInit].
    - LorenPechtel 4y ago
      Which works in *most* cases. I forget the details but I do recall running into a case where it was griping erroneously (it couldn't reach the use without having reached the initialization) so I gave it a harmless initial value--and it turned around and complained (correctly) that the assignment would never be used. I insist on removing all such warnings so I ended up restructuring the code so the compiler wouldn't get confused. (Fundamentally, this was a case of a child operation that *might* be needed. It could have been rewritten polymorphically but that would have involved a fair amount of refactoring.)
      - pjmlp 4y ago
        Declare the variable closer to its definition point. Also such kind of situations are usually a sign that code blocks should be moved into a separate function.

lmm 4y ago

> If you forbid illegal states you end up with fake objects taking the place of non-existent real ones. You don't use a fake object, you use a real one of a different type. In the cases where what you want is "maybe this thing, maybe nothing" you can use an option/maybe type. In the cases where you want something else (e.g. "either this thing or an error message") you can use a type that represents that. > Yeah, well implemented nullable and not-nullable types are good but the compilers didn't have that kind of smarts in the old days. ML had well typed optionals back in the '70s. There's no excuse for using a language that needs null today.

GoblinSlayer 4y ago
In C++ std::optional<T>::value throws an std::bad_optional_access exception when the value is missing. How is this different from a NullPointerException?
- lmm 4y ago
  > How is this different from a NullPointerException? It's different because most things can't throw it. The problem isn't that your language has a way to implement a value that might be absent, the problem is that your language does't have a way to implement a (heap) value that won't be absent, except by convention.
  - GoblinSlayer 4y ago
    If the value won't be absent, then it won't throw.
    - lmm 4y ago
      I'd like to know that the value won't be absent when I build the code rather than when I execute it.

pjmlp 4y ago

Easily solved by making an error to read before write, several languages do it.

LorenPechtel 4y ago
But that's runtime expensive, or else very restrictive on the compiler. Bad data should fail fast and null is good at doing that.
- pjmlp 4y ago
  It is done at compile time. For example in C#, you would get something like "Use of unassigned local variable xyz". If the performance cost of initilizing the variable is such an unberable cost, there is [SkipLocalsInit].
  - LorenPechtel 4y ago
    Which works in *most* cases. I forget the details but I do recall running into a case where it was griping erroneously (it couldn't reach the use without having reached the initialization) so I gave it a harmless initial value--and it turned around and complained (correctly) that the assignment would never be used. I insist on removing all such warnings so I ended up restructuring the code so the compiler wouldn't get confused. (Fundamentally, this was a case of a child operation that *might* be needed. It could have been rewritten polymorphically but that would have involved a fair amount of refactoring.)
    - pjmlp 4y ago
      Declare the variable closer to its definition point. Also such kind of situations are usually a sign that code blocks should be moved into a separate function.