Comment by phamilton | Hacker News Reader

Comment by phamilton | Hacker News Reader

Parent Full thread

I like this post because it describes specific monads and why they are useful.

If I were to recommend a basic path to understanding monads, I'd say do this:

1. Understand `map` in the context of lists. This can be done in Ruby or Scala very easily if you don't want to get into Haskell directly.

2. Learn about the Maybe monad (or Option in scala). Understand what mapping an Option or a Maybe means. A simplified explanation is to compare it to a list of either length 1 or 0.

3. Learn about the IO monad in Haskell. Understand how IO monads can compose. At this point, it's ok to just say magic happens and the compiler then cause a single IO monad (the result of composing multiple IO monads) assigned to main to execute and the side effects will happen.

At that point, you've got a general understanding of how to use monads. It will actually take you pretty far.

One key point that might be a hangup is going from `map` meaning "apply this function to every element and return a new list of the results" to `>>=` meaning "apply this function as dictated by the monad and return the result". It's probably good enough to acknowledge that `map` is a simplified case of `>>=`.

In any case, as the linked article says here, you should be able to understand specific Monads fairly quickly. Perhaps truly understanding monads means knowing when to create new monadic structures but that's hardly a prerequisite to being productive with monads.

Haskell's IO monad is decidedly not useful outside the context of Haskell and pure functional programming, both of which I do not find fun. Are monads in general useful outside that context - for example, in mostly-imperative languages like Rust?

The IO and State monads is specifically to solve the problem of side effects in a purely functional language, so they are not really relevant in other languages.

But other uses of monads, like say monadic parsers could be useful in other languages. And list comprehensions is also based on a monad in Haskell - this functionality is clearly useful in many other languages.

But without some kind of syntactic sugar (like do-notation in Haskell) the use of monads becomes far to cumbersome, and it ends up being easier to solve the same problem in an ad-hoc manner.

Check out https://youtu.be/xKRndVoo2ms, it explains how monads can refactor messy things like call chaining if you're building SQL-like result interfaces.

In what language?

C++ it seems.

Thanks. The speaker mentions Haskell, hopefully the religion isn't so important as the code patterns.

Apparently the authors of Rust believe monads are useful, as they come in the standard library. Rust's Option and Result types are monads, for instance. Rust lacks a feature, called higher-kinded types, that allow you to abstract over type constructors such as Option and Result and give a name to the monad concept. Thus in Rust you can create monads by convention but cannot create a type that actually embodies that concept.

In Scala they are heavily used. Future, Try, Option and List are all monadic. I find Options to be fairly easy to understand and pretty useful. An example:

Suppose we want a function that returns C = A + B, but only if A and B both exist. Otherwise C cannot be set with a meaningful value.

In an imperative language (python-esque?)I might do something like:

  if A != NULL && B != NULL:
    C = A + B
  else:
    C = NULL

in Scala:

  val C = for {
    a <- A
    b <- B
  } yield a + b

What's the difference? In this example it is largely syntax, but let's do something with C.

  D = [1,2,3,4,5]
  E = []
  if C != NULL:
    E = [x*C for x in D]
  else:
    E = D

So now we've got some complex logic. If C is set, then we want to multiply every element in D by C and assign the result to E.

Without monads, I have to explicitly check for C == NULL before doing anything with it. The compiler isn't going to enforce that so it's possible I forgot to check and I segfault or NPE. Here's the monadic version:

  val D = List(1,2,3,4,5)
  val E = (for {
    c <- C
    x <- D
  } yield c*x).getOrElse(D)

With an Option monad, I must use C inside the for comprehension. This is enforced by the compiler. If C is None, then cx won't execute and the for comprehension will return None. `getOrElse` on None just returns whatever was passed in, which in this case is D.
So what did we gain? Again, it might just look like syntax. We swapped an `if C != NULL` and and `else` for a `c <- C` and a `getOrElse`. We actually gained some strong compiler guarantees.
Sort of a basic example and it might not be completely straightforward at first, but in my opinion once I understood how to effectively use monads (like Option and Try in Scala) my ability to simplify complex logic and be confident that it was correct increased.
EDIT: Haha... I botched my final scala example. That doesn't compile... something like:
val E = C.map{c => D.map(_*c)}.getOrElse(D)
would do the job.

"Haskell's IO monad is decidedly not useful outside the context of Haskell and pure functional programming"
That's not true. It could still be useful to build up descriptions of IO that should be executed later, and an IO monad would be a fine way to do that in a language that provided the necessary capabilities to make that convenient.

I think your description here is likely to be tremendously confusing, and I don't recommend anyone who doesn't already grok functors and monads read it...

My point is that you can actively use Lists and Options in Scala and be using monads without having any idea what a functor or monad is.
I believe that's a similar point to the article. It's easier to understand how to use specific monads than to understand the mathematical definitions of functors and monads. Knowing `fmap` is essentially distributive isn't necessary to use functors and get a feel for what they provide.

I understood your point.
I think you were unclear about what behavior belongs to monad, in a way that will confuse newcomers.
"map" (or "fmap") belongs to Functor; monads have it because they are functors.
I agree that starting with the laws doesn't necessarily makes the most sense, and that they're not necessary (though can be valuable) for use of these things... but you do need to introduce the laws early enough that they're understood by the time someone goes to write their own instances of the relevant typeclasses - otherwise they're going to get bit by something that assumes the laws hold, and they're not going to understand why.

Reply on news.ycombinator.com