9. Juni 2020

Why you should learn Haskell … even though you are never going to use it

Moritz Rumpf

Have you heard of Haskell?

"That's the niche academic programming language where everyone talks about Monads" you might say. And yes, that's the 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.

What Haskell can teach you

Coming from Java, Haskell took away a few things that I was used to. Namely, Haskell has:

  • no null value
  • 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.

You can live without null

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).

You can live without implicit exceptions

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.

Is this worth it?

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!

Where to go from here?

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.

After getting started with Haskell, you have the opportunity to further explore:

Moritz Rumpf
Backend | Product | Agile

Rufen Sie uns an: 030 – 555 74 70 0

Made with 
in Berlin. 
© leanovate 2020
hearttagtwitterfacebooklinkedinxing
Datenschutz
Leanovate GmbH, Besitzer: (Firmensitz: Deutschland), würde gerne mit externen Diensten personenbezogene Daten verarbeiten. Dies ist für die Nutzung der Website nicht notwendig, ermöglicht aber eine noch engere Interaktion mit Ihnen. Falls gewünscht, treffen Sie bitte eine Auswahl:
Datenschutz
Leanovate GmbH, Besitzer: (Firmensitz: Deutschland), würde gerne mit externen Diensten personenbezogene Daten verarbeiten. Dies ist für die Nutzung der Website nicht notwendig, ermöglicht aber eine noch engere Interaktion mit Ihnen. Falls gewünscht, treffen Sie bitte eine Auswahl: