Why Maybe Is Better Than Null
nickknowlson.com
Why Maybe Is Better Than Null
1–10 of 133 posts
Re: Why Maybe Is Better Than Null
#2Guava for Java has Optional. Very nice, except for Java's horrid syntax for generics.
Re: Why Maybe Is Better Than Null
#3Guava 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.
Re: Why Maybe Is Better Than Null
#4Relatedly, I've always been fond of Objective-C's nil, for languages without strong static typesystems.
Re: Why Maybe Is Better Than Null
#5> 1. The elimination of null. This means that all types (even reference types!) become non-nullable.
Yep, problem solved, 'billion-dollar mistake' corrected (at least for future times).
Re: Why Maybe Is Better Than Null
#6Guava 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.
Scala still has the problem that you can return null explicitly (since references on the JVM are nullable), but any Scala code which does this should probably be shot on sight.
Re: Why Maybe Is Better Than Null
#7How many problems are actually caused by null (in particular, how many billions of dollars?)
While pointers which point into the wrong place for various reasons (off end of array, previously freed memory) cause horrible issues to this day, I can't personally remember ever having a serious issue with a null pointer (they tend to crash quickly and loudly, because in all modern OSes dereferencing NULL segfaults)
Re: Why Maybe Is Better Than Null
#8How many problems are actually caused by null (in particular, how many billions of dollars?) While pointers which point into the wrong place for various reasons (off end of array, previously freed memory) cause horrible issues to this day, I can't personally remember ever having a serious issue with a null pointer (they tend to crash quickly and loudly, because in all modern OSes dereferencing NULL segfaults)
I don't know about it in terms of money loss, but generally having missed checks caught at compile time rather than having the program crash is a good thing.
Re: Why Maybe Is Better Than Null
#9How many problems are actually caused by null (in particular, how many billions of dollars?) While pointers which point into the wrong place for various reasons (off end of array, previously freed memory) cause horrible issues to this day, I can't personally remember ever having a serious issue with a null pointer (they tend to crash quickly and loudly, because in all modern OSes dereferencing NULL segfaults)
> they tend to crash quickly and loudly
In some scenarios, this is a serious issue all by itself. My day-to-day work is mostly on Android, and eliminating nullable references altogether would eliminate some crashes, which are highly visible to the user.
Re: Why Maybe Is Better Than Null
#10How many problems are actually caused by null (in particular, how many billions of dollars?) While pointers which point into the wrong place for various reasons (off end of array, previously freed memory) cause horrible issues to this day, I can't personally remember ever having a serious issue with a null pointer (they tend to crash quickly and loudly, because in all modern OSes dereferencing NULL segfaults)
The problem isn't just NULL in C. This post is talking about the entire Null/Nil reference problem across all languages that use a null-type value.
This is especially a problem in dynamic languages that sling nils around....like any major modern scripting language. Checking if a value is nil before proceeding is aping what a language like Haskell does when it pattern matches against Maybe (Just a, Nothing) albeit in a post-facto bad way. Granted, you can't really make any assertions about reflecting a maybe value in the type of a language that doesn't care about types before runtime.