Log in

No account? Create an account
Previous Entry Share Next Entry
Are there any *good* explanation of Monads?
[For the serious programming geeks only]

I was just in a conversation, and lamenting the fact that the one bit of functional programming that I just don't *get* yet is Monads. They're clearly terribly important, at least if you like to program at the high level as I like to, but I haven't yet managed to internalize them -- none of the explanations have clicked yet. In general, most get lost in the abstraction, and don't have enough solid and clear examples. This is, I suspect, one of those paradigm-shift concepts like OO, that are blindingly obvious once you *do* get it, but kind of opaque until then.

So I'm curious: do any of my programmer friends have a *good* pet site on the subject? I've read several that didn't manage to get the concept across, but I have to believe that it's possible to find the right blend of the abstract and concrete to drive the idea into my brain, expressing not just what they are but when and why you want to use them...

  • 1
I know I've got a couple of monad tutorial bookmarks squirreled away somewhere. The only one I've really got a handle on is the IO monad, which is sort of the degenerate case.

Most of my links seem to be stale. However, the Haskell wiki has a timeline of monad tutorials, which may help you choose the one you want.

Wow, that's quite a collection. (And I'm amused that they felt the need to think of it as a timeline -- it does suggest how hard the problem is.) Thanks for the pointer...

So knowing full well it'd be so over my head it'd be the Marianas Trench, I took a look at this to see if I could get any notion of the idea....and I gotta tell ya...check out "Bob the Monadic Lover". Pretty funny.

I hadn't actually heard of them till you asked the question, but my husband's rather sarcastic explanation is that it is 'side effects for functional languages'. So functional programmers can pretend they are still as pure as the new driven snow :o)

It's kinda true and kinda not. Far as I can tell, it's the way that pure functional languages get most of the capabilities that less-pure ones take for granted. Still technically pure, though, far as I can tell...

Personally, my approach to getting it would be to do some hacking about in Haskell.

True. But I've been meaning to do *that* for 15 years (I think it was about '95 when I first started messing slightly with Haskell), and it just hasn't happened -- I haven't gotten a good excuse to use it in any depth. So in practice, I suspect I'll wind up learning monads in the context of Scala...

Hmm. Scala doesn't need an IO monad, or a State monad, right? (I've just barely started looking at the language, but I know it has mutable vars, and the first programs in the tutorial print text.) So any monad work you did there would be the more challenging stuff, like parsers. Probably a good thing; I know my use of Haskell's IO monad doesn't teach me much, since it just feels like doing IO in an imperative language.

Correct. Scala deliberately splits the difference: it has approximately all the features of a high-power OO language and a high-power functional language. But the Scala community is slowly biasing towards functional patterns as optimal when you can use them, for all the usual reasons, so monads are at least interesting, even if not strictly necessary...

I wrote some lecture notes that explained the Monad laws in terms of "working the way you expect let bindings to work, because programming with effects works like other kinds of programming". Have no idea if that'd be useful at all, but it at least got my advisor and a bunch of MIT students further along the road of understanding.

Sadly, writing bad monad tutorials is a rite of passage for Haskell programmers. Let us speak no further of "Monads as envelopes", my circa-1995 effort in this direction.

  • 1