By all means, have more clumsy, less straightforward ways to represent the lack of a value in your code, because Tony Hoare says so.

An Optional type is more clumsy than null checks and null returns sprinkled everywhere??

The problem with NULL is that it can be there for literally any reference in your code. So, unless you are careful, you can get an NPE when calling any single object method. In languages without NULL this can never happen making them much easier to reason about.

My initial reaction: programming ain't bean bag. Them's the breaks.

Then I think of it and I see the real problem is languages making all nonprimitive types into pointers without being explicit. In a language like C it's more obvious what can be null.

If null can be problematic then certainly making it more obvious when you might have a null is a pretty good idea. I tend to think, however, that getting rid of null completely as a concept is even better. One less thing to worry about.

A NullPointerException is unchecked as well. I would say about 40% of our code is checking for null to avoid NPEs especially with APIs. You have to protect yourself and cannot take nothing for granted.

Despite what he says, I don't think Hoare actually invented the "null pointer", as address 0 for "not exists" or "end of list" was probably a common convention ever since linked structures existed and independently discovered by many others. (The other convention would be the all-bits-1 value, but I'd assume that testing for 0 was easier and thus more widely adopted. Also, "0 = nothing" makes great sense.)

IMHO Optional just feels like another typical Java dogmatic overabstractionism. "Null pointer exception? So what? Just catch it." Then again, I mostly use C/Asm.

Given that the Option type has existed in programming languages other than Java for decades I don't think it makes sense to call it a "typical Java" thing.

I can see how a C/Asm programmer wouldn't like it though. Very different mindsets. :)

The difference is that other languages which originally had the Option type don't have null, so it's the only option. I meant it's typical of Java to take features from other languages, resulting multiple slightly-different-but-incompatible ways to achieve the same thing.

I certainly agree that Java would be a much better language if NULL could be eliminated completely. Backwards compatibility though...

sigh

Yeah, Optionals came from other languages, not originally Java.

IMO the problem with Optionals is that they'll never suffice unless they are part of the language itself, like in Swift. As this article pointed out, Optionals aren't supported in any existing APIs, so you still have to do a ton of null-checking everywhere. And there is nothing that guarantees an Optional reference itself can't be null, which is why you really want language-level support.

I'm probably being a bit too pedantic here, but strictly speaking they don't need to be part of the language at all. You just need basic support for (generic/parametric) algebraic data types.

For example, Haskell has Maybe which is not part of the language nor treated specially by the compiler in any way. It is part of the Prelude (think "standard library"), so that (basically) all libraries can agree on what "Maybe a" means.

In other paradigms (Lisps) null is a lot less than a billion dollar mistake, it seems it goes better with map/filter/fmap patterns. In imperative languages, data is tied to control, and null means segfault.

When some ELisp code crashes in my emacs with an error like:

  error: (stringp nil): not a string

I think it indicates Lisps suffer from this problem too...

It does, I said 'a lot less' not 'zero dollar mistake'. Recursively defined lists take care about nil, and since it's one of the most used ways to program in lisp it makes a lot of logic nullproof.