I strongly disagree. If you're expecting the first value of a list, what use is nil?
If you have a list of Ints, then what can you do with nil returned? It's not an Int.
Nils have a habit of propagating through the whole type system, and you then need to have rules about how they apply to every function. (What is 1+nil? What is nil:[1,2,3]?).
Eventually every single function will either have odd behaviour when confronted with a nil, or will be a source of exceptions (which are generally undesirable in a pure functional setting).
Haskell encourages you to write patterns that check for these edge cases, and handle them explicitly:
Why would you have nil in a list of integers? In cases where you encounter nil instead of some type you look for you can add behavior to nil without doing if nil? in the function all the time.
I would agree that not having nil is better if you have these big typesystems but for a dynamic languge its hard to avoid.
Question: Don't these static langauge use "unit" to signal what nil would do in clojure (in some casses)?
If you have a list of Ints, then what can you do with nil returned? It's not an Int.
Nils have a habit of propagating through the whole type system, and you then need to have rules about how they apply to every function. (What is 1+nil? What is nil:[1,2,3]?).
Eventually every single function will either have odd behaviour when confronted with a nil, or will be a source of exceptions (which are generally undesirable in a pure functional setting).
Haskell encourages you to write patterns that check for these edge cases, and handle them explicitly:
foo [] = ...
foo (x:xs) = ...