"That's the niche academic programming language where everyone talks about Monads" you might say. And yes, that's language I want to talk about. More specifically, why it's worth learning Haskell, even though you will never use it in your professional career.
Coming from Java, Haskell took away a few things that I was used to. Namely, Haskell has:
- no
nullvalue - no exceptions (like
IllegalArgumentException.java) - no implicit side effects, e.g. no
System.out.println("just for debugging") - no OO-style classes/objects
- and therefore: no inheritance
Let's have a look at some of these features to find out why it's good that Haskell is missing them.
Also called the billion dollar mistake, having no null is actually a blessing.
Let's have a look at the following java method signature.
public User getUser(String userId) The signature says that it returns a user. But what if there is no user for the specified id? Will it return null? Probably, but we can only be sure by looking at its implementation.
So what do we do in Haskell? The same method signature in Haskell would mean that we always return a user.
getUser :: String -> User If our method should be able to return no user for a specific id, we have to make that explicit.
getUser :: String -> Maybe User Here, the signature already tells us, that we might not get a user back.
It's very similar to Java's Optional type.
You will have to handle both cases (Just and Nothing) in the calling function, meaning you cannot get something like Java's NullPointerException.
message :: String
message = case getUser("1") of
Just user -> "I found: " ++ toString(user)
Nothing -> "I could not find the user"It is very relieving to not having to worry about null values. Using the Maybe type in Haskell will make you more familiar with similar concepts in other programming languages (like Java's Optional).
Let's have another look at our getUser method.
@NotNull
Public User getUser(String userId) Ah, so we know that it will not return null. That's good, but what happens now when there is no user for the given id?
if (userFromDatabase == null) {
throw RuntimeException("No user found for the given id!")
}Aha! It throws an exception that we can only observe at runtime or when looking at the implementation of the method.
So what would you do in Haskell? You will quickly learn about the Either type.
getUser :: String -> Either Error User Here we declare that we either get a User or an Error back. The Either is very much like the Maybe type, but instead of giving you nothing or the value, it gives you an error or the value.
message :: String
message = case getUser("1") of
Right user -> "I found: " ++ toString(user)
Left err -> "Got an error: " ++ toString(err)There is no analogous type for Either in Java like there is for Maybe. There are libraries that provide this type, like vavr, but I haven't used them enough to know if this really a good fit for Java.
After dealing with Either in Haskell, I now know how helpful it is to always have explicit error return values. In some cases, expressing exceptions as normal return values is less cumbersome than using the dedicated exception system.
Yes! Quite a few more concepts from Haskell translate in other languages as well. I would definitely recommend you give Haskell a try. See which learnings from Haskell you can use in your favorite language!
If this blog post has made you curios, I encourage you to get started with Haskell by reading Learn you a Haskell. If starting with a book feels too slow for you, I can also recommend these excellent slides to get started (update 11/04/2022: unfortunately the website is down).
After getting started with Haskell, you have the opportunity to further explore:
- Monads, one of the concepts behind the
MaybeandEithertypes - Elm, a much simpler language for the frontend with a Haskell-like syntax which inspired redux
- Quickcheck, a property testing library also implemented in many other languages
- Typeclasses, a way to extends functionality also known as traits in Rust or Scala