I was one of the "eye rolling" crew, but was struck by your comment. So below is my perspective regarding null's as learned over several decades and multiple p

I was one of the "eye rolling" crew, but was struck by your comment. So below is my perspective regarding null's as learned over several decades and multiple programming languages/paradigms. Conceptually, null is a sentinel value representing nonexistence within a value domain. Memory pointers/object references are the archetype of null's use, but as others have pointed out SQL's null support is another. The key takeaway, though, is the concept of "sentinel value." For a (pardon the pun) non-null example, consider the sentinel value "-1" in the domain of integer file descriptors returned by the "open" POSIX function[0]. Sentinel values, by definition, put the onus of discovery on the code which receives it since they can be the result of any computation which can produce a respective domain value. This complicates usage but must be done for correct programs. As a result, it is very common to normalize sentinel value discovery through the constructs available in the language being used in an attempt to minimize defects related to "missing a sentinel." In my experience, this naturally led to modelling the expectation of sentinel values in its own container type, one where the cardinality is either 0 or 1. Common names for a container with 0/1 cardinality are "Option", "Maybe", and "Nullable." Again, the key takeaway here is that these types in this context serve to normalize the detection of sentinel values wherever a domain value can be produced. Depending on the language used, "lifting" sentinel values into an option type might be not worth the effort. But the handling of sentinels must always be addressed. 0 - https://en.wikipedia.org/wiki/Open_%28system_call%29#C_library_POSIX_definition https://en.wikipedia.org/wiki/Open_%28system_call%29#C_libra...