I wondered if anyone knew the origins of the phrase “nil punning”. I presume it preceded Clojure?
Bonus question - does anyone know of a library in Java that attempts nil punning in its common collection implementations (without changing everything to use Optional)?
Having re-read Erics article more carefully I see it very thoroughly covers this.
It never once occurred to me that “nil punning” was to do with the word “pun”. I’ve been trying to work out what I thought it meant:
onomatopaic perhaps (“take that nil!” … pung!)
like “dead panning”, (not reacting to a wierd result)
nil “punting”, (“this is not my problem…”)
To me what I find wonderful about nil punning is the ability to cope gracefully with a lack of information - thereby handling unreliable data sources, expansion of a contract prior to new information becoming available, and software “growth” in the sense that Rich covers brilliantly in “Maybe Not”. The act of information processing becomes like panning (that word again) for gold in a river of nils, letting them flow on without caring … It is a wonderful asset of Clojure and yet such a difficult one to understand why you would miss it - and therefore a hard sell for those from a Java background who are conditioned to be strict with contracts to the point of letigiousness. I wondered if all those outcomes was prefigured in the origin of the term. It’s not really - but the actual origin of the term is quite poetic enough.
The word “pun” itself apparently stems from the verb “pound” as in “consolidating earth”. Perhaps anything is polymorphic when you pound it into a protocol (Nil points for that pun!)
When I first used McCcarthy’s lisp, we used nil in place of false. It took up two bytes less. Or we were just lazy.
I still use it for punting a result. Languages like Scala, Rust, and others are very proud to have Option or the like. Somehow they convince themselves that it is safer. I have yet to see code where it did anything more than take three lines of code for every semantic statement. Nil isn’t as useful as a non-signaling error return value. When you need one of those, you need a very domain specific error handling. In which case neither approach is appropriate.
The only time I’ve found the phrase useful is if the conversation is talking explicitly about the topic. It’s pretty much like air, you don’t think of it unless you stop breathing.