I think this opinion makes some sense from a pure-functional standpoint, but not from an imperative one. In imperative programming, where you're managing lots of state, it's important to be able to represent the concept of a slot with nothing in it.
That said, I think a large portion of the problems caused by null could have been avoided by making one small change to its behavior: accessing a member (or element) of a null should evaluate to null instead of throwing. This is deeply intuitive and is the biggest cause of null pointer exceptions. If you try to access a.b, and a is null, it makes perfect sense that b is also null. Many languages have recently started adding an "optional chaining" operator that works this way, but a lot of pain could've been avoided if things were this way from the start.
This has nothing to do with functional vs imperative programming, of course functional programs also want to encode the absence of things.
The billion dollar mistake is about not being able to say that a type (specifically a reference/pointer) does not include NULL/nil/whatever as an element.
I don't agree that this is a good behavior. I rarely need that behavior. NPE means that I forgot to handle null. And handling null usually means something other than use null for a result. NPE is hard to miss and stacktrace points exactly to the code that should be fixed. Propagating null will hide the code that should be fixed. I think that NPE behavior is the best solution without changing type system (and null-aware type system is just the best solution).
That's just your personal experience. Here's one from me: I use it all the time. I wish this was how js worked or that chaining operator would become standard soon. Reason is, there are times where you need some deeply nested variable in state, but it may not be already initialized, so you need to check it every time you access it. Gets tiring really fast.
I would extend on this idea. Whenever exception were to be thrown we could result in null instead. We would end up with error-free programs instantly. Good luck looking for root cause of strange results.
Note that I didn't suggest this for method calls, only for property access. Again, it's extremely intuitive that a nothing's property is nothing. Making that logical extension is not sweeping errors under the rug, it's dovetailing them into a format where they can be implicitly handled by logic that already exists. I.e., if(a != null && a.b != null && a.b.c != null) becomes if(a.b.c != null). It doesn't make the problem go away, but it certainly mitigates it.
Fair point. This might be a trade off for instant error reporting / ease of exception handling. I would strongly forbid any coersion of null to other values if this idea was to be implemented.
Solution to the problem is already there: Kotlin, TypeScript, Rust, Crystal, Swift, Haskell just to name few.
We just need to push the industry toward better and safer languages. We keep building an abstractions on top of unsafe languages and then we are suprised that it suck.
That said, I think a large portion of the problems caused by null could have been avoided by making one small change to its behavior: accessing a member (or element) of a null should evaluate to null instead of throwing. This is deeply intuitive and is the biggest cause of null pointer exceptions. If you try to access a.b, and a is null, it makes perfect sense that b is also null. Many languages have recently started adding an "optional chaining" operator that works this way, but a lot of pain could've been avoided if things were this way from the start.