On: What I Wish I Knew When Learning Haskell

[mightybyte]

1. Monads are an exceedingly common abstraction that can help you avoid code duplication, especially the duplication of control structure code. In Java:

    String postIdString = getHttpRequestParam("postId");
    if ( postIdString == null ) {
      return null;
    }
    Integer postId = Integer.parse(postIdString)
    if ( postId == null ) {
      return null;
    }
    return db.getPostById(postId);

It gets even uglier when you can't just short-circuit out of the whole function in the error case by returning null. This pattern of checking for null between statements is captured by the Maybe monad. In Haskell it would look like this:

    runMaybeT $ do
        postIdBS <- MaybeT $ getParam "postId"
        postId <- hoistMaybe $ fromBS postIdBS
        MaybeT $ getPostById postId

The Maybe monad implements the core pattern, then that behavior is extended to other contexts by the MaybeT monad transformer. This example just lets you handle failure without giving you an indication of where the failure happened. If you need error reporting along with that, you can get it very easily with the Either monad and it's corresponding transformer EitherT like so:

    runEitherT $ do
        postIdBS <- noteT "getting post ID" $ MaybeT $ getParam "postId"
        postId <- hoistEither $ note "parsing post ID" $ fromBS postIdBS
        noteT "retrieving post from database" $ MaybeT $ getPostById postId

2. Monads in Haskell provide a way to isolate and control side effects. I gave a presentation about this almost a year ago.

http://vimeo.com/59215336

The presentation is built around two real examples of software engineering problems that I encountered in my career. One encountered in a Java project, and one in a Haskell project. The thesis of the presentation is that monads are much more useful when combined with Haskell's strong static type system and purity. This also suggest a pretty good explanation of why pg doesn't talk about them--he's more of a dynamic language guy.

Here are a few of the concluding bullet points from the presentation.

Monads can:

3. Help you prevent data corruption in concurrent applications in pursuit of shorter critical sections and reduced lock contenion.

4. Prevent bugs that might arise from confusion between different phases of execution.

5. Guide exploration of complicated problems

6. Expand your dictionary of concepts and ways of thinking about a problem.

[chowells → mightybyte]

Monads are number 1 from that list.

Numbers 2, 3, and 4 are the result of a powerful static type system, purity, and having typed IO. Nothing you listed has anything to do with being a monad. They're just examples of things you can do with types.

Your numbers 5 and 6 are sort of accurate. It's true that you can say "Hey, I think this type might form a monad," and explore from there. But if it does, it's nothing greatly interesting - you just get to take advantage of a bunch of existing library code. (And a little syntactic sugar, in Haskell.)

[mightybyte → chowells]

Right, my presentation is clear that it's not just monads, but rather the interaction of purity, strong types, and monads that gets us those benefits. I list them when people ask about monads because, while they might not be what monads are actually about, they were big things that Haskell gained with the introduction of monads. So I think they're an important part of the explanation that we give to Haskell newcomers.