Live data from Hacker News

Why Maybe Is Better Than Null

nickknowlson.com

131–133 of 133 posts

Re: Why Maybe Is Better Than Null

#131
post #12

In comparison to Haskell, null in Java is similar to adding an implicit Maybe a instance for every type a. In doing so, Java makes it just that much easier to create bottom values when they are not desired (e.g., dereferencing a null pointer).

I disagree. If null was like Maybe, than you should be able to do: E foo; ... foo=foo.bar().bat() without having to do a null check after each function. I think that Java's approach has the worst of both worlds, because there is no way to make foo.bar().bat() safe when a function could return null. In C, for example, calling a method on a null object does not cause an error. Rather it passes in null as the 'this' val…

Null is like Nothing, nullability is like Maybe, and (.) has an implicit fromJust.

Re: Why Maybe Is Better Than Null

#132

Earlier quoted context omitted.

For all fixed length two's complement integer types the smallest representable number has no additive inverse, too.

Prelude Data.Int> minBound + minBound :: Int16 0

Ohhh yes, of course, it is still a abelian group.

Re: Why Maybe Is Better Than Null

#133

I can't believe there is no mention of Ceylon here. Ceylon has an elegant approach to this using union types. Typesafe null and flow-dependent typing There's no NullPointerException in Ceylon, nor anything similar. Ceylon requires us to be explicit when we declare a value that might be null, or a function that might return null. For example, if name might be null, we must declare it like this: String? name = ... Whic…

That is exactly equivalent to Haskell's Maybe, except I don't know if it's possible to abstract over type constructors in Ceylon to implement eg. Functor and Monad.
Post reply on HN