Null References: The Billion Dollar Mistake
This old chestnut again.<p>There is an inherent problem in designing processes and writing code to capture them: The notion of not-a-value.<p>There are great many ways to solve them. The most common ones are &#x27;null&#x27; and &#x27;Optional[T]&#x27;. Neither just makes the problem magically go away. If a process is designed (or a programmer writes it) thinking that &#x27;ah, well, here, not-a-value cannot happen&#x27;, but it can, then.. you have a bug.<p>Some language features might make it possible to help reduce how often it occurs, but eliminate it? I don&#x27;t think so.<p>Imagine, for example, in an Optional based language, that you just map the optional to a lambda to execute on the optional, and the behaviour of the optional is to then simply silently do nothing if it&#x27;s optional.none. That&#x27;d be a much harder to find bug than a nullpointer error. (errors with stack traces pointing at the problem are obviously vastly superior to mysterious do-nothing behaviour with no logs or traces of any sort!).<p>Some other creative solutions:<p>* [Pony](<a href="https:&#x2F;&#x2F;www.ponylang.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.ponylang.io&#x2F;</a>) tries to be very careful about registering when an object is &#x27;valid&#x27; and when it isn&#x27;t, and when you write code, you have to say which state the objects you interact with can be in. This lets you avoid a lot of the issues... but pony is quite experimental.<p>* In java you can annotate any usage of a type with nullity info, and then compiler linter tools will simply tell you that you have failed to take into account a potential null value. You are then free to ignore these warnings if you&#x27;re just writing test code, or know better. Avoids clogging up the works with optional, but as the java ecosystem shows, you can&#x27;t just snap your fingers and make 30 years of massive community effort instantaneously instantly be festooned with &#x27;might-not-hold-a-value&#x27; style information. At least the annotation style gives the hope of being backwards compatible (to be clear, optional, for java? Really bad idea).<p>* in ObjC, if you send a message to a null pointer, it silently does nothing, in contrast to virtually all other languages with null types where attempting to message a null ref causes an error or even a core dump.<p>* Just write better APIs. Have objects that represent blank state (empty strings, empty collections, perhaps dummy streams which provide no bytes &#x2F; elements, etc). For example, in java: Java&#x27;s map (a dictionary implementation) has the `.get(key)` method which returns the value associated with that key, and returns `null` if there is no such value. About 6 years ago another method was added in a backwards compatible fashion (so, all java map implementations got this automatically): `getOrDefault(key, defaultValue)`. This one returns the provided default value if key isn&#x27;t in the map. You&#x27;d think optionals provide a general mechanism for this, but, in scala, you have both: There&#x27;s `someMap get(key)` which returns an optional, so to get the &#x27;give me a default value&#x27; behaviour, that&#x27;d be `someMap.get(key).getOrElse(defaultValue)`, but maps in scala also have the java shortcut: `someMap.getOrElse(key, defaultValue)`. Sufficient thought in your APIs mostly obviates the issues.<p>null is not a milion dollar mistake. It is a solution to an intrinsic problem with advantages and disadvantages over other solutions.