What is null — and why its inventor called it a billion-dollar mistake

In 2009, at a conference in London, computer scientist Tony Hoare walked on stage and apologized. For one small idea he came up with in 1965 while building the ALGOL W language. The talk was called "Null References: The Billion Dollar Mistake."

The idea is null. A value that means "nothing." It has lived in almost every language since, and it breaks programs every day. Probably yours too — you just didn't know its name yet.

What null is

null is deliberate emptiness. Not zero, not an empty string, not an error. An honest "there's nothing here, and that's fine."

Picture a form with a "Middle name" field. Some people don't have one. Leaving the field empty isn't forgetting to fill it in. It's an answer: "no middle name." That's null.

const user = {
  name: "Anya",
  middleName: null,   // no middle name — and we know it
  avatar: null        // picture not uploaded yet
}

The difference from zero matters. 0 is a number, a quantity. "" is text, just empty. null is the absence of a value altogether. A cart with zero items is 0. No cart at all is null.

null and undefined: two kinds of empty

In JavaScript, emptiness comes in two flavors, and beginners mix them up constantly.

• undefined — "no value was given yet." A variable was declared but not filled. Or you asked an object for a field it doesn't have. It's emptiness by default — the language sets it on its own.
• null — "the value is empty on purpose." A person sets it (or code the AI wrote) to say: "I checked — there's nothing."

A simple rule: undefined is "nobody asked," null is "we asked, and the answer is nothing."

In practice they're often checked together, and that's fine. One detail for future surprises: typeof null in JavaScript returns "object". It's an old bug from the very first version of the language, never fixed — so millions of sites wouldn't break.

Where "Cannot read properties of null" comes from

This is where null hits hardest. The most common JavaScript error looks like this:

TypeError: Cannot read properties of null (reading 'name')

Translation: "you asked emptiness for its name field." The code reached user.name, and user turned out to be null. Emptiness has no fields. The program crashes.

Why does it happen all the time? Because AI-written code is almost always written for the happy path: the data arrived, the user logged in, the picture exists. In real life:

• the user hasn't logged in yet — user is still null;
• an element wasn't found on the page — document.querySelector(...) returned null;
• a record in the database has an empty field — null came back.

That was Hoare's "billion dollars": any variable can turn out empty, but the code doesn't remember that. Every such hole is a future crash.

How to stop hitting this error

Modern JavaScript has two tiny operators that handle most cases. When you see them in AI code, you'll now know why they're there.

?. — "if it exists." The question-mark dot stops at emptiness instead of crashing:

user?.name   // if user is empty — returns undefined instead of crashing

?? — "and if it's empty, use this." It plugs in a fallback:

const name = user?.name ?? "Guest"

The line reads almost like English: "the user's name if there is one, otherwise Guest."

The main tip isn't about syntax, though — it's about the prompt. When you ask AI to build a screen, add one sentence: "keep in mind the user may not be logged in, and the data may not be loaded yet." The model will dutifully add the checks it skips by default. That's cheaper than later reading the error in production.

Where null enters your project

It helps to know the "suppliers" of emptiness by sight — then you add the check in advance:

• the database — an empty column in a table comes back as null;
• searching the page — querySelector didn't find the element;
• auth — before login, the user is null;
• an API — the server returned null where a missing object would be.

How is null different from an empty array?

An empty array [] means "there's a list, and it has zero items." null means "there's no list at all." The first gets a "nothing here yet" message; the second usually means the data didn't load.

Does Python have null too?

It does — it's called None. Same idea: a deliberate absence of a value. And a similar error: 'NoneType' object has no attribute.

Can I just put "?." everywhere and forget about it?

Better not. ?. hides emptiness but doesn't explain it. If data is missing where it absolutely must exist, it's better to see the crash right away than a silent blank screen.