Why Scala’s “Option” and Haskell’s “Maybe” Types Won’t Save You From Null

I think you're missing a point here, I'm not much into scala but looking at the example from the post you've given link to (http://blog.danielwellman.com/2008/03/using-scalas-op.html) I see what authors really meant.

import scala.collection.mutable.HashMap
val map = new HashMap[String, String]
map.put( "Hi", "Dan" )
map.put( "Hello", null )

Here we've set up the same Map as we did in Java, but we imported Scala's mutable version of a HashMap. Now let's make the same queries into the map:

scala> map.get( "Hi" )
res1: Option[String] = Some(Dan)

Here the Map has the requested key, and returns a Some[String] which has contains the value of "Dan".

scala> map.get( "Hello" )
res2: Option[String] = Some(null)

In this case, the key does exist, so it returns a Some class containing the value null.

scala> map.get( "Gutentag" )
res3: Option[String] = None 

See the difference between Some(null) and None?

Some(null) == object is defined and references null

None == object is not defined/ uninitialized

 I think that's the whole point. It doesn't savne you fron checking null pointeers, but it does enable you to distinguish between unnintialized value and valu initialized with null (if you'r into thiskind of programming).

We have gained because we have done this deliberately. The insidious problem of null is that it is generally impossible to know whether a reference can be null, whereas we always know an Option can be None. x.foo() doesn't look any different whether or not it can throw a NullPointerException.

"The worst part about this example is that it forces me to deal with the null case right here. Sometimes, that's what I want to do but what if such an error is a programming error (e.g. an assertion error) that should simply never happen?"

There's nothing to stop you from throwing an exception at this point. Option has .get, which gives you the value or throws an exception. Again, the distinction is that dereferencing an Option looks different to dereferencing a nullable variable.

I'm pretty sure we've discussed this in the past; I'm surprised you still don't understand this, Cedric.

I'd agree with Josh Berry and take it a step further -- the shining benefit is when used with monadic computation.  Josh's examples are of that sort.  As are your Fantom examples (when you note that Str? is basically a less verbose way of writing Option[String]).  Either is another great example from Scala -- it largely replaces the explicit boilerplate required for exception handling.

I'd read just about everything you were talking about and I didn't get the point when I did, either.  Its probably the case that it clicks differently for everyone but I can tell you that the moment I "got it" was when I read the first few pages of the Haskell All About Monads Tutorial.  Now, I don't know Haskell... but the core points of the language are pretty simple and anyone who knows Scala can easily comprehend the first bit of this tutorial.  It really communicates why you would care about monads, and when and how you write and use them.

The worst part about this example is that it forces me to deal with the null case right here.

You've chosen a poor example. Matching on an Option is silly, because there are methods that can deal with the None case for you.

Here's how a Scala equivalent of your Fantom example might look:

    val email: Option[String] = users.flatMap(_.get("ben")).map(_.email)

Or, in for-comprehension syntax:

    val email: Option[String] = for (userList <- users; user <- userList.get("ben")) yield user.email