[tikhonj]

No. The idea is that you can get rid of null-the-value by having a Maybe type. They serve exactly the same purpose; having a null value in every type is like making each type implicitly wrapped in a Maybe.

The reason we can compare the type and a value is because they serve exactly the same purpose in different ways. The core argument of the article is that we should get rid of null because Maybe does the same thing in a safer way.

[pubby]

Pardon my confusion, but is null referring to that of Java-style reference types, in which case the article is really about those? The value itself seems irrelevant as null is practically equivalent to Nothing. Now, if comparing the types then I'd say that Haskell's Maybe has the following improvements over Java-style optional:

1. Opt-in

2. Not tied to reference types

3. Safe extraction/"dereferencing". ie case expressions rather than Java's implicit "Maybe t -> t"

All of which aren't restricted to a static type system.

[acomar]

Yep, you've got it exactly right.

The problem for dynamic type systems is how do you enforce 3? Do you care to?

[geon]

I suppose you could write a sort of safe Maybe template class in c++. You could pass in two callbacks to handle Just and Nothing respectively. It would be really ugly, but should work, right?

[pubby]

Yeah, a function taking two callbacks is what I had in mind. This works in dynamic typed languages too, although obviously not as well.

[nickknw]

Author here, that's it exactly.