Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Maybe Is Better Than Null

nickknowlson.com

Post reply on HN
Print view View original

71–80 of 133 posts

Re: Why Maybe Is Better Than Null

#71

Post by kelnos »

So maybe this is just a terminology thing, but, isn't Maybe the same thing as:

1. By default all types are non-nullable. 2. You explicitly mark if you expect that a value could be null. 3. The compiler helps you by either making sure you check for null on those values you mark, or by doing some magic (like Scala does) that will always return null for expressions where one of the values is actually null.

Is the reason we call it Maybe/Option/whatever just to disambiguate with the traditional use and lack of safety in what pretty much all languages use "null" for? Or is there a distinction I'm missing?

Re: Why Maybe Is Better Than Null

#72

Post by papsosouid »

gizmo686 wrote: post #65
nilkn wrote: 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…

I agree that C handles this much better than java. But your description is inaccurate. In C there are no methods, objects or 'this', which is far better.

Re: Why Maybe Is Better Than Null

#73

Post by drorweiss »

jeremyjh wrote: post #69
[deleted] wrote: post #55

[deleted]

I think you should reserve judgement until you've worked with a more sophisticated type system than Java. I held the same opinion for quite some time but Scala and Haskell have showed me that much more is possible than I expected. Still, on balance I prefer dynamic languages because I don't like to spend time defining and using type relations but I am no longer sure I really know which way is "better" for many types…

I worked with statically typed languages (mostly Java) for many years and just recently started working with dynamic languages (python and javascript with node).

I think it depends mostly on the task at hand... if you're on a small project with a small team, then probably the dynamic languages are more suitable. With larger teams, it starts to pay off to have more info encoded in the type system, so that everybody is on the same page.

For a small startup, trying to get a product out quickly, the dynamic paradigm is a game-changer. Not only in the programming language, also using nosql database was a game changer for me in terms of development speed.

Re: Why Maybe Is Better Than Null

#74

Post by MichaelGG »

kelnos wrote: post #71

So maybe this is just a terminology thing, but, isn't Maybe the same thing as: 1. By default all types are non-nullable. 2. You explicitly mark if you expect that a value could be null. 3. The compiler helps you by either making sure you check for null on those values you mark, or by doing some magic (like Scala does) that will always return null for expressions where one of the values is actually null. Is the reason…

The difference is that Maybe or Option is something you can implement in library code, it does not require any special compiler implementation.

Also, most languages require something to be a reference or pointer to be null. You can't have a plain int or structure be null.

Re: Why Maybe Is Better Than Null

#75

Post by tikhonj »

kelnos wrote: post #71

So maybe this is just a terminology thing, but, isn't Maybe the same thing as: 1. By default all types are non-nullable. 2. You explicitly mark if you expect that a value could be null. 3. The compiler helps you by either making sure you check for null on those values you mark, or by doing some magic (like Scala does) that will always return null for expressions where one of the values is actually null. Is the reason…

Yes, it's the same idea. The main difference is that Maybe is just a normal type in languages like Haskell and OCaml--you do not need any especial compiler support for it.

So to use Maybe, all you need from the compiler is to not have nulls everywhere. Since you don't need language support for it, your language is simpler and the Maybe behavior is part of a library.

This also ensures that you Maybe values behave as first-class citizens. You can do anything with the Maybe type that you could with any other type, because that's all it is. For example, this means that you can nest them: have a Maybe> value, for example. It also means Maybe can play well with other libraries; for example, inn Haskell, it works immediately with the alternation operator:

    result = tryA "foo"  tryA "bar"  tryB
Part of the beauty is that is an operator that represents alternation for a whole bunch of other types as well. There are a whole bunch of other functions like this.

So: yes, you can have language support for it. But just having it as a normal type makes the language simpler and ensures you have full generality. The only thing that you need from your language is to get rid of null.

Re: Why Maybe Is Better Than Null

#76

Post by venomsnake »

dscrd wrote: post #64

If you work on types that might be null, you're bloody careful or you're in the wrong profession. We're not calling incompetent programmers a gazillion dollar mistake, even though they probably have caused as much.

Not everyone has the profession of herding spherical cows in vacuum ... in the real world lots of stuff can bait you in the ass.

Re: Why Maybe Is Better Than Null

#77

Post by yew »

dllthomas wrote: post #67
yew wrote: post #49

Earlier quoted context omitted.

Give me a statically typed Python and a type system that can handle external hardware poking around in its memory and I'm in ;) I'm sort of a fan of Haskell already, to tell you the truth.

> Give me a statically typed Python Not sure that's so far from Haskell, really... :-P > and a type system that can handle external hardware poking around in its memory Can it be in isolated places? That's doable...

Not sure that's so far from Haskell, really... :-P

Maybe it's my lack of experience talking. Haskell feels heavier in a lot of places. I think the focus on compilation in the backend is almost a downside here, too.

Can it be in isolated places? That's doable...

Depends on the application. There's a lot of hardware out there that does really weird stuff. There's some interesting work in Haskell-space (eg Atom) but I don't know how comprehensively mature it is.

Re: Why Maybe Is Better Than Null

#78

Post by pjscott »

svachalek wrote: post #27
tikhonj wrote: post #13

This article makes it seem like you'd have to explicitly check whether a Maybe value is Nothing when you use it. This is certainly safe , but it's also very awkward; as a contrived example, adding two numbers would look like this: case a of Nothing -> Nothing Just a -> case b of Nothing -> Nothing Just b -> a + b This is quite a bit of boilerplate hiding the expression that actually matters--a + b! Moreover, whenever…

Ah yes, wonderfully clear syntax: do a

The use of Haskell here was just for illustration; there's nothing stopping a programming language designer from having clear, convenient syntax for dealing with Maybe values.

Re: Why Maybe Is Better Than Null

#79

Post by pjscott »

pubby wrote: post #36

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?

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.

Re: Why Maybe Is Better Than Null

#80

Post by pubby »

tikhonj wrote: post #43
pubby wrote: post #36

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?

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…

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.

Post reply on HN