Monads in Clojure | Hacker News Reader

Monads in Clojure

intensivesystems.net

71 pointsrohshall17 comments

I appreciate these attempts to give non-Haskellers a chance to learn Monads but, personally, I never really grokked them until I got into Haskell. In Haskell, Monads are defined in terms of types, thus languages without type systems like Haskell's make the concept both more difficult to understand and less (immediately) useful. Having been through many of these tutorials myself, I think the best way to get into Monads (as well as many other useful constructs like Functors, Monoids and Monad Transformers) is to roll up your sleeves and learn Haskell (Learn You A Haskell is a great and relatively quick read). As a bonus, you'll also learn one of the most elegant programming languages around.

This comment isn't intended as a knock against the article. I think there's a lot of merit in using monadic constructs in languages that aren't Haskell, I just think Haskell's type system makes understanding the concept easier.

I don't really have the experience to comment on this issue, but I did try looking at another monad tutorial in Clojure several months ago. I think I kind of got the idea behind monads, but I always thought so what. I have no experience with Haskell. I supposed that may be the reason.

I disagree. The only sensible introductory text I've found about them is for Scheme - http://www.cs.indiana.edu/~cswords/monads.pdf. Folks love to emphasize the types - but how one might implement them matters just as much if not more IMO.

Also, I've found the usage of monads as the building blocks for modular interpreters to shed the most light on their power, utility, and limitations (see the various papers from Steele, Wadler et al, Hudak et al, and Felleisen et al).

> but how one might implement them matters just as much if not more IMO

This is a false choice. Learning monads through Haskell, you get the forest and the trees! That said, I get that there are legitimate differences of opinion and what worked for me will not necessarily work for others. I feel like some understanding of types (or categories, etc.) is necessary to fully grok monads. Both this article and your linked paper offer some basic explanation of the concept. Tutorials that are essentially implementations of bind are, in fact, missing the forest for the trees.

Really your choice for an introduction to monads puts this in an intro paragraph?

Before we begin, it is important to brieﬂy talk about the λ- calculus in the context of termination. In short, the λ-calculus is strongly normalizing and thus non-termination is impossible as a general rule.

I think it's a "to each his own" thing. Personally I've always found Haskell's syntax to be distracting. The operators are kind of visually "thick" and the prefix/postfix/infix mix obscures the logic for me.

Of course, this is because I only barely grok Haskell. If I really knew Haskell I'm sure I wouldn't have an issue with the syntax, but as someone trying to learn about Monads from a category-theoretic perspective, Haskell just ends up confusing me more than the extra annotations provided by its type system can compensate.

I found I understood monads a little better after this article, because the Lisp syntax is uniform enough that it disappeared into the background. The lack of type annotation brings some fresh confusion right back in, but that's the cost of using Clojure for this example.

Again, all of this is just how my own brain works. Your brain may vary :)

An interesting approach would be to try teaching monads with typed Racket. [1]

[1] http://docs.racket-lang.org/ts-guide/

If you're coming from a mathematical perspective (I should note that I didn't but kind of wish I did), then the Haskell type system has an additional advantage: it's very obvious how Haskell types form a category and I've found it's very easy to visualize how functors, monads and so on "look" (for lack of a better term) on the category of Haskell types.

Of course, I'm really trying to do the opposite--get a basic understanding of the math from using functors, monads and so on in Haskell. I also read about type theory for fun, so maybe I'm not the least biased person to ask about static typing :P.

I've been spending some time to try and pick up Haskell and I just thought I'd mention that I found "Real World Haskell"[0] to be a bit more understandable and accessible to me than "Learn you a Haskell".

Different strokes, obviously, but just thought I'd mention an alternative.

[0]: http://book.realworldhaskell.org/

> The idea behind a monad is to factor out the plumbing code so that its complexity is hidden, leaving only the composition of the functions visible.

cue light bulb coming on

Thanks so much for this article; I've been trying to understand monads forever now. The closest I got was the "burrito" analogy, but I always wanted a more mathematically sound intuition.

For helpful reference, here's a collection of monad tutorials and related pedagogy:

- Monads are burritos [https://speakerdeck.com/u/dimituri/p/a-monad-is-just-a-burri...] (slide deck)

- No, they really aren't [http://byorgey.wordpress.com/2009/01/12/abstraction-intuitio...]

- Well yeah, they kinda are [http://blog.plover.com/prog/burritos.html]

- But anyway, you probably have already invented them yourself; you just didn't realize it [http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...]

- And even if you didn't, you can always learn about it from that crowd-sourced fountain of programmer knowledge, StackOverflow (and this question hasn't even been closed as "not constructive"!) [http://stackoverflow.com/questions/44965/what-is-a-monad]

- Of course, once you understand basic category theory, you should be set anyway. What are you, some kind of Java programmer? [http://reperiendi.wordpress.com/2007/11/03/category-theory-f...]

- But really, a monad is just a monoid in the category of endofunctors, what's the problem? [http://stackoverflow.com/questions/3870088/a-monad-is-just-a...]

The author of this article, Jim Duey, has written some newer introductions to monads in clojure on his new site: http://www.clojure.net/archive.html

Just a note for anyone hoping to follow along at home: clojure.contrib has been deprecated and the various parts have either moved or been left to bitrot on the vine. Pertinent to this article, "clojure.contrib.monads" is now "clojure.algo.monads".

You can find out what happened to the rest of clojure.contrib here: http://dev.clojure.org/display/design/Where+Did+Clojure.Cont...

I met the author (after having seen his video of this subject) at clojure/conj 2011. Fascinating guy, and can really explain this stuff in more or less terms I can understand.

I don't use it enough to "get it" so I have to re-learn it every time I feel the need to, but this is the go-to spot for me.

Nice article. On the other hand, in a slightly joking manner, I really wonder how some people can live with 8-space tabs with 8+ levels of indentation!

The lisp code in the article doesn't do indentation by a fixed number of spaces. It indents syntactically, i.e., aligns depending on the current depth-level of the s-expression).

It IS really nice to see something on those mysterious monads not written in haskell. I got hung up early into the article though, where the author says something to the effect of "the monad hides the complexity", and that seemed like a silly goal. I need to make another pass at it.

Hiding complexity is almost the whole point of most programming languages and a big reason why most of the popular library and frameworks exist. Computer programs are fiendishly complex things, and they're only getting more so as time goes on (now we have several independent processors doing complex things simultaneously in the service of even larger complex things). A lot of software is so big that even most of its components are too much to fit in your head at once. So I think hiding complexity is a pretty sensible goal.

I remember how happy I was the first time I really grasped my nads.

Reply on news.ycombinator.com