FP For The Working Programmer: Why Is null Bad?
Null is dangerous. This is a tough statement to accept for a lot of people I’ve worked with. The concept of null is deeply ingrained into the languages we use. In C/C++, if you access a member of a null pointer, the program can sometimes continue to run but generate strange results. This led to bugs that were sometimes very difficult to trace. Java improved the situation by causing programs to fail the instant a null pointer was accessed.
Failing sooner rather than later makes bugs easier to trace, for sure. What if we could make the compiler disallow nulls?
There are two kinds of values, (1) the ones that are there and (2) the ones that might not be. The trouble with the type systems of Java/C#/…/Ruby is that you can’t tell the difference between these types. The null value is implicitly always available, so you have to always check for it even though it may not even make sense.
Newer languages like Scala offer an Option type that represents something that can have no value. Here’s the example in Scala:
The Option
type wraps a value; Some("fred")
is non-null and None
a lot like null. You can’t access the value inside the option directly - name.length
would result in a compile error. This could get cumbersome so the Option type has methods to make them fun again.
getOrElse(other: T): T
- get the value inside the option, otherwise use a default valuefilter(predicate: T => Boolean): Option[T]
- returns anOption[T]
but may turn a Some into a None.map[U](function: T => U): Option[U]
- safely converts the inner value to something elseflatMap[U](function: T => Option[U]): Option[U]
- safely converts the inner value to another option
Once you get comfortable with Options, your start writing less code and with fewer bugs. At some point you’ll find that, more often than not, the types only get in the way of the mistakes. We’re starting to see Option-like concepts in Java, C# and C++. We’ll talk more about Options later, but for now I’ll leave you with this gem: