🇳🇱
Interesting thing about boolean in most languages is that it is often a trinary/tri-state variable, not a dual state true or false variable, reason being you often have nil/null you can set a boolean too as well and in many languages, particularly those where all variables are by reference, you cant change this.
Ruby is particularly interesting because it makes a distinct separation between a variable being not-set and null/nil. Therefore a boolean in Ruby is a quad-state variable that can be either not-set, nil/nill, true, or false.
NOTE: My comment about Ruby is actually misleading since its a dynamic language. If you have a variable intending to act like a boolean, strictly speaking, before you set it with a boolean variable it doesnt have a boolean type. So the boolean **type** is not quad-value. Its just any variable that the variable you intend to use exclusively for boolean can have any of 4 states, and likely does in most implementations.
@torresjrjr
While nil/null isnt really quite so horrible as the author makes it sound I do agree that the Option/Maybe approach as done by Haskell is much nicer. Null still exists but it isnt universal, we get to decide when its allowed and when its not without explicitly guarding for it (defined in the type)... All this really does is move null from a runtime check/guard to a compile time check. But generally the more you can move to compile time the less errors that can crop up at runtime. So it does add value getting rid of null IMO.
@Science