Nil is not a first class value. It has a recurring scheme of cases
where it has a strange kind of double-meaning, nil as variable not
there, and nil as a result of something not-being there stored in a
variable, now not there. Same with recent discussions what to do if
inserting nil into a list. Or people requesting how to differ if a
function was called without a parameter or with nil as parameter. This
can be achieved in lua with select('#', ...) and only highlights more
the funky meaning of nil. This problems might exist more in heads of
the coders than the language/interpreter, since when learned all the
details how nil behaves you can work with it. However, even if so, a
good programming language should be aimed just as much to the heads to
coders than of cpus - thats all what in my opinion object oriented
programming was about - to better fit in the way we humans think
natively. The issue most directly on hand is type-safeness and let
errors happen where they occur instead of returning nil and error
later. local condition = some_function(); if conditonn then --- will
always silently fail, even if some_function returned true.
