3 ms·

I think that a proper understanding, and awareness of the import of, of nil, null, None and other empty/bottom types and values is a very pressing need in progr

by sn41 6y ago

I think that a proper understanding, and awareness of the import of, of nil, null, None and other empty/bottom types and values is a very pressing need in programming languages and databases (see the intricate discussion on SQL NULL [1]). It is wrong to dismiss this as mere "WTF" caused by pragmatic implementation goof-ups. There is a deep philosophical issue here which needs to be one of the first issues to tackle when implementing a system, rather than an after thought. An analogy I can think of is recursion: the base case needs as careful a thought as the inductive case, otherwise the code will go into an infinite loop. Empty values and types are probably the base case of a type system, and have to be handled meticulously and in a logically sound manner from a programming language theory persepective. [1] https://en.wikipedia.org/wiki/Null_(SQL) https://en.wikipedia.org/wiki/Null_(SQL)

wwwigham 6y ago
Too bad nil/null _aren't_ typically bottom types or "base cases", but rather are real, runtime values that are sentinel values of some kind, rather than valid references to a value of some type. A distinct sentinel value that, for some usually historical reason, your compiler often thinks is OK to pretend is some interface, right up until it blows up at runtime. I get the confusion, though, since the same compilers that make that mistake often attribute some bottom-type-like characteristics to nil/null to facilitate using it (eg, considering it a valid possible value of all other expressable interfaces). Empty values and other sentinels are meaningfully different from a type-theoretic bottom type. Real bottom types don't come up much in mainstream languages - TypeScript has `never`, Scala has `Nothing`, and both typesystems have distinct representations of various `null`s and other empty values. Such uninhabitable bottom types see most of their use in describing generic constraints in situations where variance comes into play. I think the real "WTF" here is that the go compiler quietly makes a simple `nil` written in your code into one of potentially many nil-like sentinels at runtime (contrary to what one may think), coerced depending on usage, and, moreover, that a simple `==` comparison or reflective call alone is insufficient to detect all of them. The semantics of how such a sentinel is coerced (and reflected) is surely in the realm of language esoterica and not simple beginner knowledge.
lifeisstillgood 6y ago
Add in Nan's as well - and then try to discuss the difference between 'show 0% show 0, show a blank and show a null and what's a NaN' in the report to senior management.

by sn41 6y ago

wwwigham 6y ago

Too bad nil/null _aren't_ typically bottom types or "base cases", but rather are real, runtime values that are sentinel values of some kind, rather than valid references to a value of some type. A distinct sentinel value that, for some usually historical reason, your compiler often thinks is OK to pretend is some interface, right up until it blows up at runtime. I get the confusion, though, since the same compilers that make that mistake often attribute some bottom-type-like characteristics to nil/null to facilitate using it (eg, considering it a valid possible value of all other expressable interfaces). Empty values and other sentinels are meaningfully different from a type-theoretic bottom type. Real bottom types don't come up much in mainstream languages - TypeScript has `never`, Scala has `Nothing`, and both typesystems have distinct representations of various `null`s and other empty values. Such uninhabitable bottom types see most of their use in describing generic constraints in situations where variance comes into play. I think the real "WTF" here is that the go compiler quietly makes a simple `nil` written in your code into one of potentially many nil-like sentinels at runtime (contrary to what one may think), coerced depending on usage, and, moreover, that a simple `==` comparison or reflective call alone is insufficient to detect all of them. The semantics of how such a sentinel is coerced (and reflected) is surely in the realm of language esoterica and not simple beginner knowledge.

lifeisstillgood 6y ago

Add in Nan's as well - and then try to discuss the difference between 'show 0% show 0, show a blank and show a null and what's a NaN' in the report to senior management.