3 ms·

After 35 years of hearing debates and suppositions on null in C, C++, and <insert modern programming language here>, I feel that "null discussions" now metaphor

by cubano 8y ago

After 35 years of hearing debates and suppositions on null in C, C++, and <insert modern programming language here>, I feel that "null discussions" now metaphorically model null itself, as they share all the same features... reference undefined state ... check! contain no useful information ... check! causes confusion in programmer ... check! are defined differently in each instance ... check! I think I could go on, but perhaps you get my point.

forgottenpass 8y ago
>After 35 years [] I feel that "null discussions" now metaphorically model null itself, as they share all the same features... I think this goes the same for a lot of unfortunate design decisions throughout computing that like to get bikeshed with the benifit of hindsight. Like, yeah, sure, there's this foot-gun. And, yeah, we've probably found better options in the intervening years, or ways to use the feature more delicately where it is the right option. But hot takes make for better conversation than reasonable discussion. Even on Hacker News, the person I want to hear from most is the one rolling their eyes and closing the tab without taking the time to write a comment.
- DoofusOfDeath 8y ago
  So, you like the null-comment? ;)
- AdieuToLogic 8y ago
  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...
skywhopper 8y ago
This is true, and yet, this article has none of those problems. In fact, to me it was an interestingly fresh perspective on the purpose of Null, and how explicit Null is just one possible approach to a consequence of programming languages that's ultimately unavoidable. And even explicit Null has huge variety in how it might be implemented, and that how your program interacts with the language's decisions around how to deal with Null/Maybe/Optional should be part of your design process and style decisions.

by cubano 8y ago

forgottenpass 8y ago

>After 35 years [] I feel that "null discussions" now metaphorically model null itself, as they share all the same features... I think this goes the same for a lot of unfortunate design decisions throughout computing that like to get bikeshed with the benifit of hindsight. Like, yeah, sure, there's this foot-gun. And, yeah, we've probably found better options in the intervening years, or ways to use the feature more delicately where it is the right option. But hot takes make for better conversation than reasonable discussion. Even on Hacker News, the person I want to hear from most is the one rolling their eyes and closing the tab without taking the time to write a comment.

DoofusOfDeath 8y ago
So, you like the null-comment? ;)
AdieuToLogic 8y ago
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...

skywhopper 8y ago

This is true, and yet, this article has none of those problems. In fact, to me it was an interestingly fresh perspective on the purpose of Null, and how explicit Null is just one possible approach to a consequence of programming languages that's ultimately unavoidable. And even explicit Null has huge variety in how it might be implemented, and that how your program interacts with the language's decisions around how to deal with Null/Maybe/Optional should be part of your design process and style decisions.