My point is that, for me, Common Lisp is particularly defficient in this regard, in a way that means I can't really consider using Common Lisp for development work today.
Different programming languages play different games with booleans, empties, undefinedness and such. In all of them, people are able to Get Stuff Done, correctly handling inputs from the world.
In the POSIX shell, a failed termination status of a command is a false condition. Storing false as a datum is usually represented by an empty or unset variable.
Yet, people are able to write robust shell scripts to boot systems, build programs and so on.
Everything you wrote is based on a guess; not even anecdotal experience. That is below the expected level of discussion on HN.
The nil/empty/false thing is an excellent tradeoff in code that manipulates lists, rendering it succinct. For instance an expression like (when attributes (do-this ...)) means, (do-this ...) when attributes are present; i.e. the list of attributes is not empty. All the default nil return values that occur are automatically empty lists, which is very convenient. For instance a two-clause if (if condition then) returns nil if condition is false. If the caller expects a list, then that is perfect; it's the empty list. All these little conveniences dove-tail together to clarify the code.
The empty/false conflation doesn't do anything in code that doesn't manipulate lists. For instance, if you're manipulating numbers, or strings, there is no ambiguity: nil isn't a number and it isn't a string. It is distinct from 0, 0.0, and "".
You cannot have a meaningful opinion about this that anyone should take seriously unless you have experience with it: having experienced both the convenience in writing list manipulation code (particularly code-writing code) and the situations in which the ambiguity between nil (the atom) and nil (the empty list) was actually a problem.
In the POSIX shell, a failed termination status of a command is a false condition. Storing false as a datum is usually represented by an empty or unset variable.
Yet, people are able to write robust shell scripts to boot systems, build programs and so on.
Everything you wrote is based on a guess; not even anecdotal experience. That is below the expected level of discussion on HN.
The nil/empty/false thing is an excellent tradeoff in code that manipulates lists, rendering it succinct. For instance an expression like (when attributes (do-this ...)) means, (do-this ...) when attributes are present; i.e. the list of attributes is not empty. All the default nil return values that occur are automatically empty lists, which is very convenient. For instance a two-clause if (if condition then) returns nil if condition is false. If the caller expects a list, then that is perfect; it's the empty list. All these little conveniences dove-tail together to clarify the code.
The empty/false conflation doesn't do anything in code that doesn't manipulate lists. For instance, if you're manipulating numbers, or strings, there is no ambiguity: nil isn't a number and it isn't a string. It is distinct from 0, 0.0, and "".
You cannot have a meaningful opinion about this that anyone should take seriously unless you have experience with it: having experienced both the convenience in writing list manipulation code (particularly code-writing code) and the situations in which the ambiguity between nil (the atom) and nil (the empty list) was actually a problem.