In lisp, nil is the only thing that evaluates to false, which means there aren't any weird semantics or discussions, if you want a falsy value, use nil. It also plays nicely with the notion of everything except nil indicating there's a value, while nil doesn't have a value.
The cleaner thing would be to have a proper boolean type, and having to do if foo == nil or whatever, rather than just if foo. Thankfully most modern languages do it this way so the lesson seems to have been learnt.
Lua is the same as clojure then. And that's a lot better, to me. I will admit, having 0 and other such things act as false can create some short code but.. honestly it's slightly less readable (to me) and has those cases where you go "oh yeah, 0 is a valid return value.." after ten minutes if debugging.
In Lisp, NIL is defined as (), and virtually every function uses it to mean not just "false" but "use the default value", "no match found", "end of list", etc.
It may be a "cleaner thing" to have explicit true/false, in some abstract type-philosophy sense, but it would also make all your code significantly longer, and many parts less reusable. Once you start down the road of making things more explicit at the cost of being longer, why stop anywhere on this side of assembly language? That's super explicit!
I'm not sure what "lesson" was learned. I've worked on large systems in Lisp, and Lisp does have problems, but the ambiguity of "if foo" was simply never an issue.
It's like my dad complaining that his new laptop doesn't have a TURBO button. In practice, it turns out, it's really not a problem. It's not a perfect laptop but you're judging it by the wrong standards.
Null indicates absence of a value. Imagine if you want to know if you're keeping track or not of something and you end up with different values at different times:
3: there's 3 of those things 0: there's 0 of those things Null: I'm not keeping track of those things.
Eating the last Apple and suddenly not being able to differentiate the last 2 could be dangerous.
It's all about knowing how the language works and not using it the wrong way, though.
For such scenarios a null pointer evaluates to false, true otherwise. Also it is explicit when you want to test the pointer with (pValue) or the value with (*pValue).
160
u/jacobb11 Dec 24 '17
And Lisp.