Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My suspicion is that no one wants to explain monads because if they did it would be painfully obvious that they're a purgatorial way of getting around the basic mismatch between functional purity and actual computers.


Monads for all your I/O yeah, probably kind of dumb. Monads as a tool for dealing with cross-cutting concerns? Ridiculously useful. http://reasonablypolymorphic.com/blog/ideas-and-men has some basic examples.


In Haskell and PureScript, Monad is a typeclass just like any other.

They are an abstraction, effectful computation is not inherent to them, they represent computational contexts, e.g. the list monad is used to model non-determinism, the maybe monad represents computations that can fail, both of these are pure.

This is an excellent set of posts for building an intuition about monads: http://mvanier.livejournal.com/3917.html


> the list monad is used to model non-determinism

See this is the kind of thing that made learning Haskell so hard for me. I'm not a math guy, I'm terrible at math. I have no idea what "non-determinism" means, and I'd venture to guess that list monad is used to model "ordered collections of things".


Scala calls the monad bind "flatMap". Java actually implements it for Streams.

If you have a `Stream<Deck> decks;` of card decks, and want to get all the cards from all the decks, you might try to do something like `decks.map(deck -> deck.getCards().stream())`, but that will give you the type `Stream<Stream<Deck>>`. That sucks, we just want a single stream, not a stream of streams, so we call the function that flattens at the same time. `decks.flatMap(deck -> deck.getCards().stream())`.

Nondeterminism is just a standard use for this construction: given one choice, generate more choices, given that choice, generate more choices, do some computation with the choices, and then return the list of possible final results.


I'm not a math guy either and I did indeed find it difficult to penetrate the inner sanctum of Haskell for this very reason. I won't say I've completely succeeded in that effort, but I've come quite a long way.

I'm fairly certain that in this context, non-determinism means that there can be more than one answer/result.


"non-determinism" implies unordered.


See, to me, the sequence of keypresses I make while banging on my keyboard seem like it could be represented as an ordered list. I may be missing something, though.


If something is unordered it does not mean it may not be ordered. It only says you cannot assume that it is ordered. (A Collection in Java/C# is an unordered contract, but a List is also a Collection.)

But the idea of a list also suggests an ordering to me.


Actually, it's the other way around. Monad tutorials are so frequent that it's become a meme among Haskellers that everyone will eventually write a monad tutorial to relay his own mental model of monads.


And as someone who's read what is probably most of those tutorials - I fulfill the other half of the meme.

"To understand monads, you first need to understand monads."


Sorry -- you're right. I should have said "explain monads well."


Naw, everyone who understands monads wants nothing more then to explain it. Hence the profusion of tutorials and over-focusing on the concept.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: