back
13 comments
Well, this is a load of hogwash.

Null is definitely the billion dollar mistake. It’s not the “null” value however, since this could indeed be seen as a badly implemented option monad.

It’s the implicit nullability of all reference types which is the mistake, since it leads to undefined behaviour at runtime.

Also; in regards to the linked style discussion in the post; you’re wrong about all of it :p

> It’s the implicit nullability of all reference types which is the mistake, since it leads to undefined behaviour at runtime.

How does the implicit nullability of all reference types lead to "undefined behaviour at runtime" in, for example, Java or C#?

I'm aware that dereferencing NULL pointers in C/C++ is undefined behavior, but I haven't seen this in any other language.

That’s fair. Unexpected might indeed be more generally correct.
Maybe "unexpected" would be a better term
That's the same mistake. A type system that can't have NULL doesn't have a reference type that can be NULL.
The biggest problem is always just going to be that it breaks any understanding or concept of a type system. When object.doThing().doOtherThing() can fail because the result of doThing() can be null, you suddenly have to fill your entire code base with unreadable cruft to avoid that happening. Because it's not just that one method where this is possible.

It especially doesn't help in languages like Java, where nulls completely subvert static types and static type checking and it turns a whole class of issues into runtime errors.

Allowing null means you're implicitly codifying Type class | null for every single reference type everywhere in your code. By doing it implicitly, you're not providing any semantics in the programming language or in the runtime to be able to deal with it at the same abstraction level as the code around any particular point where something can be null. This is incredibly error prone and makes for ugly, brittle code.

Yeah, it's a billion dollar mistake.

I agree. The way everything is null by default in Java basically makes it impossible to fix the problem. Using Optional only acts as documentation, not as reassurance that the API works the way you think.

While Optional being nullable is aesthetically ugly, you're going to crash on the next method call in the Optional class sooner rather than later if someone got the silly idea to return a null instead of Optional.empty(). What's far worse is that in the case of someone not using Optional, you simply have no idea whether you should expect null or not, so you assume null is possible either way, gaining you nothing. In an ironic twist, Optional tells you when the return value is unlikely to be null. The exact opposite of how it should work!

Then there is all the legacy code (yes it is legacy code by now) written since 2020 taking advantage of Java records. An obvious opportunity to make record fields non-nullable by default was wasted! I await the day they introduce class2 and record2 keywords to fix the defaults...

With my LLM written Java code I prompt for null checks using assert statements during one of the improvement iterations. Any reference variable that could be unexpectedly null is followed by a null check immediately after its assignment.

Given that Java source code will increasingly be written by AI, it makes sense to incorporate coding patterns that are both defensive and clear for an AI to read.

Additionally, LLM code generation understands and writes Java using null values to represent cases of object absence.

> JavaScript itself is a beacon of usefulness that is inversely proportional to its purity or beauty, so long story short: ...

How can I take this seriously. The language's shortcomings is from being written practically overnight, not from inverse proportional value elsewhere. This post might be a $100 mistake.

Where UserName Is Not Null

Filters out the records where UserName is not Null.

Where UserName Is Null

Filters out the records where UserName is null and possibly didn't finish the registration process.

Coincidentally surely, and not Dunning-Kreugur, that this exact thing proved to be another literal 2 comma line item just last week.
Dunning-Kruger
Stopped reading at "Functional programming languages like to make use of the Optional “monad” ... but that’s just another way of modelling NULL." It is clear he doesn't understand simple things like Option and the purpose of that and monads.