Comment by schwurb | Hacker News Reader

Comment by schwurb | Hacker News Reader

For 99% of people, monads are best understood by a) using and writing many monadic interfaces and b) forgetting about the whole mathematical background.

What a monad offers is: "1: Do A. After A is done, you can inspect the result of A and do either B or C. 2: You can chain monads of the same type together.". Sounds easy? It is because it is!

The big fuzz about Monads is mainly because prior to monads, doing IO was akward in Haskell. Monads offered a convenient way to do IO (and other interactions with the outside worlds, such as databases, networking, ...) and turn up basically everywhere. There is nothing stopping one from introducing a monadic interface in OO-World, and it is partly done (i.e. "orElse" or "then") in some domains. However, bigger gain is to be expected in Haskell, since the type checking system forces the developer to deal with monads in a disciplined way.

-----

I admit being guilty of having only the title prior to writing the comment. But even with only having read just the word 'monad' in the title together with 'lazy', I knew the author would describe 1) some way of lazily evaluating one thing after another and 2) some way of combining multiple lazily evaluated things with each other. After skimming, this is what the article is about. As always, the interesting stuff is not about the concept of a monad (which is pretty easy), but about how to model/code 1) and 2) in a specific context (in this instance, being lazy evaluation).

Monads in OO-world often fall flat because monads usually add something to a computation (ability to store state, ability to throw exceptions, ability to do I/O, ability to return `null`, etc) and in Haskell the basic building block is the pure function which can do none of those things. But in (say) Ruby, every method I write has already been given rights to return nil, write to the logging system, delete the database or launch the missiles no matter from where it is called in the program. The ErrorT monad transformer is much less useful when exceptions are a key part of the language and intended to be used everywhere.

Indeed, some design patterns (and monad is a design pattern) are more useful in some languages and less so in others.

There is a famous quote from a mathematician (maybe von Neumann, don't have it to hand) to the effect that you don't understand mathematics, you just get used to it. That's how monads work. You won't figure them out from thinking through the definition or listening to other people's explanations, but you will start to feel comfortable with them if you use them enough.

A mathematical analogy from introductory analysis is the concept of a dense set. If you're encountering the concept for the first time, it's easy to understand the definition, but it's hard to see why it matters. Then you start using it to solve problems and write proofs, and it's incredibly useful. After a while, you get a feeling about it, an intuition about when it might be helpful, and a facility at working through the technical details of using it. You get used to its power, in a way that feels like understanding. But you don't learn anything that can be passed on in words or symbols. You can't say anything to a beginner to clear up their confusion. You can only point them towards the exercises through which you acquired your understanding. Monads work exactly the same way.

https://www.youtube.com/watch?v=ZhuHCtR3xq8

I found Brian Beckman's video Don't Fear the Monad was extremely helpful for understanding monads as a practical user. I now use them everywhere. I don't know the first thing about category theory.

Reply on news.ycombinator.com