Hacker News new | ask | show | jobs
by pubby 4807 days ago
Does that article title pass a type checker? How can you compare a type (Maybe) with a value (Null)?

Is this instead arguing Maybe vs pointers? No, that can't be right; pointers are just type-safe as Maybe, albeit less general.

I guess it's a dynamic vs static typing argument in disguise?

2 comments

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.

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.

Yep, you've got it exactly right.

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

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?
Yeah, a function taking two callbacks is what I had in mind. This works in dynamic typed languages too, although obviously not as well.
Author here, that's it exactly.
In the title, the words "Maybe" and "Null" are values of the type "Strategies that a programming language can take for dealing with nullable values." There is no type mismatch; there is ambiguity in the syntax, but type inference clears it up.