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.
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...
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.
Coincidentally surely, and not Dunning-Kreugur, that this exact thing proved to be another literal 2 comma line item just last week.
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.
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...