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

91–100 of 133 posts

Re: Why Maybe Is Better Than Null

#91

Post by happy_dino »

kruffin wrote: post #23
bajsejohannes wrote: post #14

Earlier quoted context omitted.

I've worked with a code base in C++ where the code base would accumulate significant amounts of if (argumentX == null) return null; at the top of function signatures. It was just defensive programming. Maybe argumentX couldn't be null, but it would take time to figure that out (sometimes I did that, though). More code means harder to read and maintain, thus costing dollars. This would also be contagious: If a piece o…

I'd certainly prefer to be able to reason about the code with the safe assumption that certain things cannot be null. You can do this, but if you want it to be maintainable, you'll also want to detail in the function comments this technical debt. If you don't, someone else will come along and see your sweet method (looking only at the comments) and use it where the input can be null. Ex: /** * This does some stuff. *…

Why do you consider this a debt? It's pretty much the only sane thing to do.

If people want to pass lazy NullPointerExceptions, it's their fault.

Re: Why Maybe Is Better Than Null

#92

Post by acomar »

svachalek wrote: post #40
tikhonj wrote: post #29

Earlier quoted context omitted.

That particular syntax makes much more sense when you have functions that return a Maybe value: do a I used a deliberately overly simple example so I could go on from do-notation--which many people are already familiar with--to applicatives and idiom brackets. Besides, it looks like any normal program, except you're using <- to define variables rather than =. Can't see how it could be any clearer than that.

Except that what it looks like isn't actually what it's doing (made even clearer by the a I like the Maybe concept and non-nullable types; I just think being able to overload operators like "=" and ";" in C++ and Haskell is optimizing writability over readability and in most cases, readability is by far the more important attribute.

But you're quite clearly NOT overloading "=" or ";". Instead of saying

    do
       a = getFoo x y z
       b = getBar p q
(which won't compile), you're saying

    do
       a
Which is not an overloaded operator. In fact, it's not even meant to suggest equals (which in Haskell rather strictly means mathematical equality) but rather assignment ("=" in the expression "x = x + 1;").

Re: Why Maybe Is Better Than Null

#93

Post by Peaker »

drorweiss wrote: post #73
jeremyjh wrote: post #69

Earlier quoted context omitted.

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…

Static languages like Haskell are the best of both worlds. You develop with roughly the same speed as dynamic languages, but then you get the performance and maintainability of static languages.

Re: Why Maybe Is Better Than Null

#94

Post by Peaker »

drorweiss wrote: post #68
dllthomas wrote: post #66

Earlier quoted context omitted.

If the database structure is encoded in your type system, and all your code that accesses the database (including the initial population of the database) is checked against that encoding, the compiler can absolutely statically check the correctness of code that relies on the structure and contents of the database. Several of the mainstream Haskell database packages do this.

Sure, I will look at Haskell. Still, IMO this may be true in theory. In practice, most of the errors we encounter come from incomplete understanding of the input we're dealing with. These are many little rules that are very hard to formalize.

Most of the errors you remember encountering, I bet.

Re: Why Maybe Is Better Than Null

#95

Post by acomar »

Bjoern wrote: post #88

Does anyone have a nice implementation of the Maybe Monad for C++ ?

There are a ton floating around, they just aren't terribly useful because every type is by default nullable. So even standard library functions can return null. You might be able to make your own code a little safer, but you still have to null check everything.

Re: Why Maybe Is Better Than Null

#96

Post by acomar »

kruffin wrote: post #39
pubby wrote: post #33

Earlier quoted context omitted.

Is that C++? Just use a reference if you want a pointer which asserts it can't be null.

It's Java ;P I haven't used C++ in a long time. But you are correct a reference does exactly what he wants. For anyone who needs to look it up like me: http://en.wikipedia.org/wiki/Reference_(C%2B%2B)

Except the reference can itself be null, which is still problematic.

Re: Why Maybe Is Better Than Null

#97

Post by acomar »

pubby wrote: post #80
tikhonj wrote: post #43

Earlier quoted context omitted.

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 expre…

Yep, you've got it exactly right.

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

Re: Why Maybe Is Better Than Null

#98

Post by acomar »

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…

How much time do you spend instead on unit tests? Is it comparable? The idea with a Haskell (or more powerful) type system is to reduce the amount of unit tests you need to write (because the compiler enforces certain rules). It's all trade offs, but personally, I know I make mistakes, and I know I won't remember to check for all possible type errors in my unit checks. So I like that the compiler does it for me.

Re: Why Maybe Is Better Than Null

#99

Post by fyi80 »

monkeyfacebag wrote: post #3
Evbn wrote: post #2

Guava for Java has Optional. Very nice, except for Java's horrid syntax for generics.

Guava is definitely cool and I recommend it whenever I can. It's worth noting, however, that, as a Java library, it cannot provide the compile-time guarantees mentioned in the post. That is, your Option type could still be null and so you're still forced to perform run-time null checking. If you want the full benefit of Option types on the JVM, you might be better off with Scala.

Yes, you'd need a linter to stop you from using explicit null in your code. but than be layered on top of javac with something FindBugs and its friend @Nullable. It's not "Standard" Java, but it is compiler-time enforcement.
Post reply on HN