Peter Seliger
2 min readSep 2, 2024

--

Quoting the author ... "This mistake has been the source of confusion and bugs ever since. [...] If you thin[k] you mess with the words, no you’re not. You read that right. null is an object, even though it’s supposed to represent the absence of an object."

The author, by stating ... "null is an object" ... just demonstrates that he too does not understand what the typeof operator and null being a placeholder for a value that is expected to be an object type both hint ... it's about a type. And even by reading it literally ... typeof null === 'object' … one can not draw the conclusion that null is an object.

If one does that, one also has to question the nature of Number.NaN. The typeof operator will unveil its type as 'number'. But NaN, as the abbreviation already tells, actually is not a number; it is a placeholder, a symbol for the absence of a meaningful number value. Thus one can even use it in every calculation. Of cause, the result of an operation where at least one NaN value is involved will always be NaN.

What I never got in the last 25 years, whenever a hype broke out about the misconception of the null value, that people go crazy about the latter's nature but never really argue against the nature/implementation of NaN. Instead of crying, they should except the standard. It's really not that confusing.

I never ever made a single mistake with null, and I'm an average programming dude. I’m always left puzzled when, with a certain regularity, the next big wave of attention washes over this humble null value, and that this little fellow, due to not having a loud lobby, has to live with the stigma of being a million dollar failure.

If people and businesses really failed that big, then they by all means did/do deserve exactly that. After all, it's not that hard ... read and know the the f**k*ng specs and act/code accordingly.

--

--

Responses (1)