Null's inventor called it a billion-dollar mistake and pointed to non-null types

Tony Hoare put a very large price tag on nothing. The inventor of the null reference later called it his “billion-dollar mistake,” which is an impressively expensive way to come up empty.

His 2009 QCon presentation, preserved by InfoQ, connects the decision to ALGOL W. The summary dates it to 1965; the show notes also use 1964. Keeping that discrepancy visible is more honest than pretending this particular historical bug has already been patched.

The talk’s record also makes the dollar figure an estimate. It is not an audited sum of the world’s crash reports. The useful question is how one convenient language decision could push repeated checking onto everyone who later uses the feature.

A reference that may contain nothing makes every use conditional. The programmer has to establish that the object exists before treating it as though it does. That is easy to describe once. It becomes less charming when the same obligation turns up throughout a large program, including places its author forgot to consider (surprise, production found one).

The presentation discusses non-null reference parameters and compile-time checks. Those move part of the obligation into the language’s rules. A compiler can object before the program reaches a customer, provided the type system actually expresses the promise being made.

The difference resembles an order form that requires an address before accepting the delivery. It cannot guarantee that every address is correct, but it can stop a particular class of incomplete orders from leaving the desk. A form that accepts a blank field instead leaves somebody else to discover the problem at the door.

That is a narrower promise than perfect software, and much more useful than advertising perfect software. Required values, optional results and failures have different meanings. An interface that shows those meanings gives the caller something concrete to follow and the tools something concrete to inspect.

Hoare’s talk also puts responsibility on language designers for mistakes made in their languages. That changes how the familiar crash gets discussed. Asking whether an interface repeatedly invites the same omission can lead to a better fix than telling another developer to be more careful, very sincerely, in the next team meeting.

The boundary remains important. A non-null promise about one value does not prove the entire computation correct, and old interfaces may still supply data that needs checking. The practical improvement comes from identifying which guarantees the tools can enforce and where the remaining uncertainty enters.

Nothing still needs handling.