While working on an article for the Monad.Reader, I’ve had the opportunity to think about how people learn and gain intuition for abstraction, and the implications for pedagogy. The heart of the matter is that people begin with the concrete, and move to the abstract. Humans are very good at pattern recognition, so this is a natural progression. By examining concrete objects in detail, one begins to notice similarities and patterns, until one comes to understand on a more abstract, intuitive level. This is why it’s such good pedagogical practice to demonstrate examples of concepts you are trying to teach. It’s particularly important to note that this process doesn’t change even when one is presented with the abstraction up front! For example, when presented with a mathematical definition for the first time, most people (me included) don’t “get it” immediately: it is only after examining some specific instances of the definition, and working through the implications of the definition in detail, that one begins to appreciate the definition and gain an understanding of what it “really says.”
Unfortunately, there is a whole cottage industry of monad tutorials that get this wrong. To see what I mean, imagine the following scenario: Joe Haskeller is trying to learn about monads. After struggling to understand them for a week, looking at examples, writing code, reading things other people have written, he finally has an “aha!” moment: everything is suddenly clear, and Joe Understands Monads! What has really happened, of course, is that Joe’s brain has fit all the details together into a higher-level abstraction, a metaphor which Joe can use to get an intuitive grasp of monads; let us suppose that Joe’s metaphor is that Monads are Like Burritos. Here is where Joe badly misinterprets his own thought process: “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.
But now Joe goes and writes a monad tutorial called “Monads are Burritos,” under the well-intentioned but mistaken assumption that if other people read his magical insight, learning about monads will be a snap for them. “Monads are easy,” Joe writes. “Think of them as burritos.” Joe hides all the actual details about types and such because those are scary, and people will learn better if they can avoid all that difficult and confusing stuff. Of course, exactly the opposite is true, and all Joe has done is make it harder for people to learn about monads, because now they have to spend a week thinking that monads are burritos and getting utterly confused, and then a week trying to forget about the burrito analogy, before they can actually get down to the business of learning about monads. (Of course, certainly not all monad tutorials are like this, and I don’t even have any particular ones in mind, just a general impression left over from reading many of them, but if the shoe fits…)
What I term the “monad tutorial fallacy,” then, consists in failing to recognize the critical role that struggling through fundamental details plays in the building of intuition. This, I suspect, is also one of the things that separates good teachers from poor ones. If you ever find yourself frustrated and astounded that someone else does not grasp a concept as easily and intuitively as you do, even after you clearly explain your intuition to them (“look, it’s really quite simple,” you say…) then you are suffering from the monad tutorial fallacy.
January 12, 2009 at 11:59 pm |
Great post mate. When writing my tutorials I try and keep this in mind. I’m certain I’ve suffered from it myself, though I am yet to be pulled up (probably coz I don’t get a lot of readers ;) ).
The heart of the point is key though. What works for you might not work for someone else. Especially when the conclusion you’ve drawn from your experience leads you to an analogy that wouldn’t have worked for you in the first place.
I am still yet to find a Monad tutorial that does a good job.
Nice blog :)
January 13, 2009 at 1:44 am |
A related article I came across this week: http://betterexplained.com/articles/developing-your-intuition-for-math/
(I have nothing to add, except, yes! Agreed wholeheartedly.)
January 13, 2009 at 2:51 am |
Absolutely. So, as a neophyte Haskell programmer I ask: where is there a catalogue of very most simple concrete examples of monad usage?
I’m currently learning the State monad. It’s a rich and powerful thing, but I struggle to learn effectively from rich and powerful examples (which is what the very small number of examples I’ve been able to find are).
Another aspect: I’ll get around to understanding how wonderfully clever monads are after I know how to be an effective programmer with them, thanks (just as I learned λ calculus after becoming proficient with Scheme).
Thus, show me how to do something very simple but useful with the State monad (even if, and this is the important bit) there is another more idiomatic way to do it, before launching into the examples that show the motivation for mondads in the first place. StgGen, I’m looking at you. Show me, oh let’s say an accumulator that walks a list adding up the values. Sure, you wouldn’t do it that way in practice, but what a great, simple example of using the tool!
January 13, 2009 at 5:41 am |
[...] key to understanding monads is that they are Like Burritos.” http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ « előző | diegoeche — 2009. 01. 13. [...]
January 13, 2009 at 7:11 am |
I would say this relates to unlearning. I do no think this is particular to monads. Monads just exemplify it well since they’re hard to understand in the beginning, have a steep learning curve and a definitive and very clear ‘aha’ point. That and the fact it does not take years to learn them. But I think this holds for all concepts we learn, just that some concepts’ aha moment is less well-defined, or takes longer to attain.
Perhaps this is due to the fact that monads have a very small interface, and thus you must understand it completely to be able to use it. There’s no partial understanding, and as such the ‘aha’ erlebnis is not smeared out.
January 13, 2009 at 10:43 am |
Makes me think of Zen koans–the sudden enlightenment that’s the result of an indeterminate amount of sometimes subconscious mental work, the way the insight can only be communicated by words or actions to someone who’s already had it, etc.
January 13, 2009 at 11:11 am |
Thanks for this great insight!
In other words, there is no way around discovering an abstraction oneself; of course guided by someone (teacher, text) who has already discovered it.
January 13, 2009 at 12:59 pm |
Look, it’s really quite simple. A monad is just a monoid in the category of endofunctors on Hask. See?
January 13, 2009 at 1:07 pm |
There is some confusion here in not paying attention to the difference between “How I learn” and “How everyone learns”. Interesting in someone from the programming community, where differences in how people use manuals are very clear.
January 13, 2009 at 1:31 pm |
This is pretty much was good teaching is about – understanding the process of learning and crafting the lesson to optimize that process for the material.
One thing I’d love to see in every aspect of higher math (and higher math tutorials) is tutorial creators adopting one little thing from Tufte: creating not just one concrete example but a whole series of such and set them side by side to allow the “whole pattern” to present itself. You can see this in the cover of his book “Envisioning Information”
http://www.edwardtufte.com/tufte/graphics/ei_bookcover.gif
The shirts at the top illustrate “shirtness” in many canonical examples. The “feel” of flag semaphores are illustrated canonically as well. It’s not that you are trying to learn every symbol represented (or may be you and you see the pattern involved also).
If someone does a tutorial on monads again (or group theory or topology or whatever), please let them use this one idea in their presentation of the tutorial.
It’s actually a good test, in fact. If you can’t come up with the example cases for such a canonical diagram or illustration, you probably don’t understand the subject well enough to be doing a tutorial!!
January 13, 2009 at 3:31 pm |
$0.02
I think I like http://ertes.de/articles/monads.html#section-4.
For me, the “laboriously threading a world as an extra argument” example makes the most sense.
Monads are a great brain exercise because they are very simple, but then quickly become complicated by all the nuances of using them in actual Haskell: which notation you choose; the error messages you get; trying to combine monads.
Also, I’d like to further your thought on the mistake people make by saying that people also learn better through different media: I really do better when there are good pictures involved, than just text and impenetrable math notation.
So, like, http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html is nice in that it has some pictures.
January 13, 2009 at 3:33 pm |
Just stumbled across this blog. I come to the idea of “monad” as a philosopher rather than a mathematician. Can anyone tell me how this mathematician’s concept of “monad” is related to Leibniz’s metaphysical concept of monad? That was the original definition of the term, as far as I know.
January 13, 2009 at 4:42 pm |
Jenny: it actually isn’t related at all, as far as I know, except perhaps in a vague etymological sense. Mathematicians have this bad habit of taking nice-sounding words and appropriating them for their own use.
January 13, 2009 at 5:22 pm |
So which monad tutorials are the best and the most concise?
January 13, 2009 at 5:27 pm |
A metaphor sets up a(n approximate) isomorphism between domains. The application of this is that a person who can reason successfully about one of the domains can then transfer this reasoning to the other. This is the primary reason for using metaphors to elucidate technical material. The first test of any proposed metaphor should be whether or not it does this. I think that in almost every case, the metaphors for monads fail.
There’s an important flipside to this too. Not only should your metaphor allow you to transfer correct reasoning from one domain to another, it should also transfer incorrect reasoning to incorrect reasoning. Otherwise your metaphor is too general. So that’s the second test for whether a metaphor is any good.
For example, the burrito metaphor is pretty poor as it stands. But suppose burritos had the property that whenevr you stuffed one burrito with a bunch more burritos, the tortilla around the inner burritos dissolved leaving just a single burrito. This would model the join property of monads quite nicely. That’s a good candidate for passing the first test. But given a burrito you can freely scoop the contents out. So burritos fail the second test because you can do things with burritos that you can’t do with all monads.
January 13, 2009 at 5:29 pm |
Jenny,
The word monad, as used by mathematicians, is a portmanteau of ‘triple’ (it’s made from three parts) and ‘monoid’ (to which it is formally similar).
January 13, 2009 at 5:57 pm |
Monads aren’t burritos they’re vegemite sandwiches! Sheesh! ;-)
Do you fancy starting a pedagogical tutorial? It might even be best not to use any particular existing implementation (e.g. State as Keith asks) but to do something that develops into a vegemite sandwich each iteration and then voila! people see what a monad is by creating one themselves.
January 13, 2009 at 5:57 pm |
That’s okay. Poets do the same thing, and interesting things can happen! I always liked the idea of muscling a word into a certain odd meaning.
January 13, 2009 at 7:53 pm |
Dan P.–well, if “mono” means “triple” or “three,” I have to leave my portmanteau at the luggage locker.
January 13, 2009 at 8:24 pm |
[...] Abstraction, intuition, and the “monad tutorial fallacy” While working on an article for the Monad.Reader, I’ve had the opportunity to think about how people learn and [...] [...]
January 13, 2009 at 9:21 pm |
Jenny:
It’s a bit confusing here because the word “category” really was borrowed directly from philosophy, but “monad” wasn’t.
Generally speaking, mathematicians like inventing words (e.g. groupoid) and naming things after people (e.g. Noetherian ring).
Computer scientists, on the other hand, like borrowing metaphors from other fields and real life. Words like “computer” and “printer”, for example, used to refer to jobs that people did. A bundle of wires that “transport” data is called a “bus”. You view your data through “windows”. Data that has a rooted branching-type structure is called a “tree”. My personal favourite is removing intermediate trees, which we call “deforestation”.
We do this partly to avoid the problem in the article. The word “monad” is scary, because it’s not based on an existing metaphor.
January 13, 2009 at 10:48 pm |
I’m happy with the idea of different fields (computer scientists, mathematicians) using words in different ways, and the idea that mathematicians aren’t borrowing from philosophy. But I seem to be grumpy when it comes to the word “monad,” which was not a metaphor but is a simple translation of the Greek word “monos,” which means “unit” or “one.” Saying “monad” means”three” is, to me, like saying “monorail” means “it travels on three rails.” It’s not a metaphor. A semaphore, maybe. You say the word “monad” is scary. I’m not scared, are you?
April 10, 2009 at 6:56 pm |
The etymology for the mathematical monad is related to the Greek, and to Liebnitz. Monads essentially define predicates, in the sense of logic. These are the “monadic predicates” of the “monadic logic”. The defining property of the monadic logic is that its predicates take only one argument — that its arity is 1. The “two argument” logic is called dyadic, and so on using Greek.
Here’s the general idea, relatively abstractly. Consider a collection of things, with rules on how those things can be “connected”. The properties of the collection that can be proved about the collection without constraint on what the objects “are” depends on the ways that the objects are connected. So lets consider the set (1, 2, 3), and say that x is connected to y by “<” if x is less than y. For example, we can prove that the set has 3 elements in it. It wouldn’t matter if the set was (5.0, 1000, 9999). The only information you need is that there are three connections.
A monad is _a_ “totality of all things” (under consideration at a given point). It is an unescapable “environment”. A domain of discourse, together with a valuation function. This ought to make the relation to Liebniz’s monads pretty clear. The world as perceived, together with an “evaluator” — opinion maker, actor, and so on form a monad.
January 13, 2009 at 11:26 pm |
Jenny: I suspect that DanPs comment was in part a dig on the mathematics-internal history of the word Monad. The underlying concept was called, before the community kinda settled on Monad, both Triad and Triple – refering both to technical building blocks of the construction as such.
I cannot – in the few minutes I’m putting into it right now – figure out what a better (i.e. more accurate) theory for the etymology of the word would be; but if you for instance go to the Wikipedia page for Monads in category theory, and follow the external link to the lecture notes by Barr & Wells, they don’t use Monad, but rather Triple in their exposition….
January 13, 2009 at 11:48 pm |
Thank you. I’ve looked at the Wikipedia page. That helps. I’m going to quietly disappear now. Goodbye.
January 14, 2009 at 7:01 pm |
I think that this could all be easily cleared up if one of you FP guys would just show us how to write one of these monad thingies in Java…
January 15, 2009 at 5:31 pm |
[...] love to point you to a good monads tutorial, but the monad fallacy prevents me from doing that. I’ll try again once I fully [...]
January 16, 2009 at 7:03 pm |
[...] be honest: is it really the names that are tripping people up, or is this just more “monads are like burritos?” Sure, you can look at a monoid and say “aha! if only someone had called this thing [...]
January 17, 2009 at 8:50 pm |
No, I’m not. But apparently a lot of programmers are. Programmers like borrowing metaphors from real life, and “monad” isn’t a borrowed metaphor.
January 18, 2009 at 3:52 am |
Phil: There are examples written, but Java doesn’t lend itself particularly well to that kind of abstraction. Thus a formal monad sometimes looks really awkward in Java.
I do recall seeing, somewhere, though, code examples that show off Monad style arguments and phenomena written in Java. Buggered if I remember where, alas.
January 30, 2009 at 3:00 pm |
[...] 2 Months. Just Obey this 1 Rule, That’s All.” It occurred to me that fad diets are like monad tutorials. Of course, since Monads Are Like Burritos (and Tutorial is a functor), it follows that fad diets [...]
February 6, 2009 at 3:39 pm |
[...] a chicken monad Yesterday, Mark Dominus took a picture of me eating a monad: [...]
February 27, 2009 at 11:23 pm |
This is a wonderful post. You’ve nailed, spot-on, a complete, big idea that had only been beginning to surface in my own mind. Doubly so, as I’m preparing a talk on monads! (I feel that they are chimichangas, though ;-)
March 2, 2009 at 12:33 am |
I like this idea so much that I’ve named my talk “Monads are Burritos” (with a sense of irony), so as to remind myself of the danger of the fallacy.
March 8, 2009 at 1:34 am |
http://twitpic.com/1xavz
April 7, 2009 at 10:03 pm |
I found a great monad tutorial: chapter 8 (“Functional Parsers”) of Graham Hutton’s book Programming in Haskell.
Interestingly enough, not only does it use no metaphors, but it doesn’t even mention monads. It just walks you through the details of bind and return. I’ve been building my own monads quite happily since I’ve read it.
But it does start to beg the question, “for what purpose is a monad tutorial?” While I came out of that one happily able to write my own monadic parsers and suchlike, it did not leave me with the ability to use all the useful monads in the standard library. The “All About Monads” tutorial helped with that, but there’s no question in my mind that the The Typeclassopedia is a very necessary thing.
cjs@cynic.net
April 23, 2009 at 6:26 am |
I may be a bit late to the game here, but Phil, that can be rephrased:
“I think that this could all be easily cleared up if one of you OO guys would just show us how to write one of these object thingies in Haskell…”
Of course you can, but it’s a different type of abstraction for a different way of thinking about programming…
June 6, 2009 at 9:49 am |
Man, i believe you stumped into something big. I mean, this “Monad Tutorial fallacy” might have single-handedly debunked Marx, quite a bunch of philosophers, a surprisingly big number of trendy scientific theories and maybe even 42! Seeing as your by-far-biggest tag is “Haskell” the blog might not be concerned about the reach of this idea beyond programming, but i am left wondering… The delicious irony is that the chosen title for the fallacy is actually an example of itself: “this fallacy is just like a bad Monad tutorial”! I would like to further explain myself, but i will have to spend some time evaluating how deeply guilty of this mistake i am myself — a lot, i fear…
August 21, 2009 at 10:14 pm |
[...] you’re trying to teach someone monads or anything else, you must read Brent Yorgey’s Abstraction, intuition, and the “monad tutorial fallacy”: But now Joe goes and writes a monad tutorial called “Monads are Burritos,” under the [...]