Brent Yorgey

First, going straight to "How do I understand Monads?" is not a good idea. I remeber when this article showed up on the web, and I remember wishing it had been written before I started learning Haskell:

https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/

If you want to understand monads, start hacking and watch for patterns.

> But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putting. At a glance it just feels super complex, academic and completely divorced from practical coding. I get vibes of enterprise java class hierarchies looking at this stuff.

Yeah, and here's my take on why it looks like that:

First, the terminology is all borrowed from mathematics, hence the academic tone. People can debate on the merits of this; I think it makes more sense when you're making tools for folks who are already familiar with the usual notation, but e.g. if you're not dealing with people who are already accustomed to the way physisicts talk about things, "p" is probably not the best variable name for momentum, traditional as it may be.

The authors of that document seem to have gone even farther in that direction than the Haskell folks -- Setoid? really? It's just fing equals! even Haskell calls it Eq. At least they kept Ord.

Also, the design looks to be basically transliterated from Haskell. There's been no attempt to adapt it to either javascript's strengths or its weaknesses. For example:
…

> Calling for lack of metaphor is interesting. In many ways, our industry is nothing but metaphors, so it is surprising for me to see them called down.

I don't think that's true. There are lots of metaphor because people love using metaphors, but it's not inherent to our industry. Abstraction is, but abstraction and metaphors are different. Metaphors seem to mostly come from blog-post type content, where people want to give you an intuition for something in less than 10 minutes. There's a really good article about this, in the context of monad tutorials, which are some of the most proheminent victims of these metaphors https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/.

> I agree that no metaphor is perfect. But, by that same logic, I would argue that no specified type is perfect. Especially if done so in a taxonomy that does not admit exceptions. (And again, I'm not against types.)

I would call types an abstraction rather than a metaphor, though I agree with you that they are not perfect, in that all abstractions trade precision and exhaustiveness for speed. There are interesting alternatives to this with property-based checking and whatever clojure.spec is, and type systems themsleves are getting better, but we're still not at perfection. And even then, I don't think we will ever reach it. The "best" type systems currently all seem to have some structural parts, and some nominal parts, so there's no silver bullet.

I mostly…

Author of the blog post here. It's amusing to see this submitted by Don Stewart, since it was his explanation[0] of algebraic data types that first made them "click" for me! I think I forgot to mention him in this post, but I remembered in the talk[1].

If anyone's interested in this and where else it might go, I recommend read Don's SO answer[0], this SO question and the related answers[2] and these papers [3,4] on derivatives and dissections by Conor McBride. There are also several good blog posts[5] and a paper[6] by Brent Yorgey on the topic of combinatorial species, and of course Dan Piponi's blog[7] is a treasure trove of interesting insights at the intersection of math, physics and computer science.

[0] http://stackoverflow.com/a/5917133/546084

[1] http://www.youtube.com/watch?v=YScIPA8RbVE (shitty audio for the first minute or 2 - it gets better).

[2] http://stackoverflow.com/questions/9190352/abusing-the-algebra-of-algebraic-data-types-why-does-this-work

[3] http://strictlypositive.org/diff.pdf

[4] https://personal.cis.strath.ac.uk/conor.mcbride/Dissect.pdf
[5] http://byorgey.wordpress.com/

[6] http://www.cis.upenn.edu/~byorgey/papers/species-pearl.pdf

[7] http://blog.sigfpe.com/2010/08/divided-differences-and-tomography-of.html

Edit: It should go without saying, but because a few people last time around seemed to think I was trying to pass this off as my own ideas, let me state that there is nothing original in this blog post. It's a repackaging of the…

> Also you need applicatives, which is just a way to box things. i.e turning a Int into a List<Int>.

Applicative functions do have that property, but their key attribute is the ability to two things together, e.g. turning a List<Int> and a List<Double> into a List<Pair<Int,Double>>. A functor which also has the ability to put arbitrary things into the functor context, but not the ability to combine two contexts, is sometimes referred to as a pointed functor. (There is no official Haskell typeclass for pointed functors; the main reason, besides historical baggage, is that non-applicative pointed functors don't have any real laws aside from the ones which apply to functors.)

Applicatives are sufficient for sequencing effects but the List<Double> in the previous example can't depend on the Int values in the List<Int>. This is great for static analysis of effects but it limits the kinds of programs you can write to those whose effects are known in advance. A monad lifts this restriction and allows effects (not just values) to be computed dynamically from the values of prior effects.

Finite[1] applicative parsers can only parse context-free languages. Monadic parsers, on the other hand, can handle context-sensitive languages (without resorting to an infinite set of production rules).

[1] https://byorgey.wordpress.com/2012/01/05/parsing-context-sensitive-languages-with-applicative/

Apple incorporated most of these patterns into Cocoa and Cocoa Touch.

Great! That means I could just learn to work with Cocoa and Cocoa Touch and skip the tedious exposition.

I would try to explain why I've never been able to pick up a patterns book without eventually throwing it against a wall, and why I prefer to encounter my patterns in the wild as I work on actual code, where I can poke and prod them and watch how they behave in practice, but it's already been throughly explained and even given a name, The Monad Tutorial Fallacy:

http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/

Sounds to me like your junior Android developers might be learning patterns just fine: They trip over one in practice, and then they learn about it with the help of their teacher. This is how learning works. There is no royal road to geometry, and beginners don't become experts overnight just by reading the right book.

You cannot really understand monads just by reading about them. Or I couldn’t, at least.

This is a very good article about the problems with monad tutorials: https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy

> “Of course!” Joe thinks. “It’s all so simple now. The key to understanding monads is that they are Like Burritos. If only I had thought of this before!” The problem, of course, is that if Joe HAD thought of this before, it wouldn’t have helped: the week of struggling through details was a necessary and integral part of forming Joe’s Burrito intuition, not a sad consequence of his failure to hit upon the idea sooner.

TL;DR There’s no beautiful explanation that will help you understand, you need to get your hands dirty with code.