https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ blog :: Brent -> [String] [brent-hiking-940x198] Skip to content * Home * About me * BlogLiterately * Catsters guide * How to print things - Data.List.Split Fad diets are like burrito tutorials - Abstraction, intuition, and the "monad tutorial fallacy" Posted on January 12, 2009 by Brent 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. Share this: * Email * Print * Reddit * Twitter * Facebook * More * * Tumblr * Related [cc11392] About Brent Assistant Professor of Computer Science at Hendrix College. Functional programmer, mathematician, teacher, pianist, follower of Jesus. View all posts by Brent - This entry was posted in haskell, learning, math, teaching and tagged abstraction, intuition, learning, monads, pedagogy, tutorials. Bookmark the permalink. - Data.List.Split Fad diets are like burrito tutorials - 128 Responses to Abstraction, intuition, and the "monad tutorial fallacy" 1. [f854] OJ says: 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 :) 2. [aa7c] Bill Mill says: 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.) 3. [050f] Keith Braitwaite says: 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 l 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! + [cbf8] Julian Gilbey says: June 3, 2010 at 1:00 pm Have a look at Paul Hudak's book: The Haskell School of Expression. He has a lovely example of essentially this; I stepped through the code on (lots of) paper, and it really began to help. Then having a several-hour conversation with a computer-science-lecturer friend of mine about what a monad is just added on to this! Good luck! + [4bd2] Jason says: June 12, 2010 at 6:56 pm I think the simplest example of a monad is the list monad. A slightly more complicated example is the tree monad. Here, return() yields the singleton list, or the tree of one node. I've reached my understanding from category theory, where return() is more commonly referred to as the unit morphism. If tutorials gave examples of lists and trees before launching into the abstract treatment, they wouldn't be too far off. The problem is, the mathematical conception is in terms of fmap (i.e. the functor), unit (aka. return), and flatten (the natural transform fmap . fmap -> Id). IO style deals with it in terms of an alternative formulation, i.e. replacing fmap and flatten with bind. The former is easier for understanding the list and tree example in my opinion, just as it is also what the category theorist is used to. It is then necessary to motivate the switch to the latter so as to explain how the IO monad works. The state monad may be a good step in the process. o [cbf8] Julian Gilbey says: June 21, 2010 at 5:13 am The functor (T), the unit natural transformation (eta:X-> TX) and the flatten natural transformation (mu:T(TX)->TX) are indeed the more common category theory notions; however, the alternative formulation is also known, and is called a Kleisli triple; it is defined in terms of T, eta and the Kleisli map which takes a function f:X->TY to a map f*:TX->TY. So the bind operator can be thought of as follows: the binding m >>= f (using Haskell notation) is just f*(m). + [c2df] Jeremy says: March 30, 2015 at 9:31 pm I think the union-find data structure would be the most compelling use of the State monad. It's not that much trouble to implement all the operations without using any monads, but using the State monad lets you put the operations together a lot more cleanly. 4. Pingback: Turulcsirip - diegoeche 5. [edf4] Christophe Poucet says: 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. 6. [5039] Steve says: 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. 7. [bcf3] apfelmus says: 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. 8. [7023] Mikael Vejdemo Johansson says: 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? 9. [9c9a] Ferg says: 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. 10. [ab57] Jeff says: 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" [ei_bookcov] 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!! 11. [5a09] Raoul Duke says: 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. 12. [1255] Jenny says: 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. + [6e0b] Jim Crayne says: May 8, 2014 at 11:10 pm I realize I am a few years behind replying here. But I recall the term Monad was also used by Robinson in his hyper-real calculus, that was in the 60s i think, when did the category theory usage begin? It may have been a progressive distortion where there actually was some leibnizian influence. I think Robinson's notion is slightly more reminiscent of Leibniz's idea, although certainly different, and it's name was probably more of a tribute than a refining of the concept. http://en.wikipedia.org/wiki/ Monad_%28non-standard_analysis%29 Did that play a role in the evolution of "Monad" as used by category theory, which inspired it's usage in the haskell language? I do not know the history... but... It's not hard for me to imagine that a hyper-real monad is an example of a category theory monad with proper definitions of arrows and such. http://en.wikipedia.org/wiki/Monad_%28category_theory%29 It's also not hard to imagine that the categoroy theory concept was devoloped completely independently and is also a tribute... Here's a possible analogy to Leibniz, In terms of a one way monad, there is no way out, only in... If we think of analysis as a sort of getting something out of the monad, then this monad cannot be described in terms of its parts, which is what Leibniz said about his monads... Maybe that's a stretch... Would love to hear if anyone knows the true etymology. o [6e0b] Jim Crayne says: May 8, 2014 at 11:22 pm Another very fascinating observation, is both Haskell and Leibniz use their respective "monad" concepts to answer this question: How do we salvage the power of a static referentially transparent descriptive language in a universe where there is unpredictability (and free-will)? 13. [cc11] Brent says: 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. + [22c9] Eric says: April 26, 2011 at 7:07 pm And there in a nutshell is the problem I have with many explanations of mathematical concepts. I find that most explanations of advanced concept Q start off promising a simple explanation but then rely on the reader's deep understanding of M and C (which we won't bother to explain because what are you even doing here if you don't know the essence and uses of M and C?) In short, I have to "wikipedia" my way through the explanation one painstaking new concept at a time. I can't help but think that a less lazy teacher of concept Q would include explanations of M and C in their treatise as a matter of courtesy. In this case, Q = Monad M = Lift C = Bind And that sort of use of wretchedly meaningless symbols (bad variable names) in math explanations is another pet peeve. Got you. 14. [3347] Dru Nelson says: January 13, 2009 at 5:22 pm So which monad tutorials are the best and the most concise? 15. [8daf] Dan P says: 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. 16. [8daf] Dan P says: 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). + [3352] decourse says: January 14, 2014 at 9:10 pm I know this is five years later, but for the record, it's "triad", not "triple". 17. [d164] JoshG says: 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. 18. [1255] Jenny says: 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. 19. [1255] Jenny says: 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. + [d4f8] James Craig Burley says: December 22, 2010 at 10:13 am I'm guessing "mon-" comes from "monoid", "-ad" comes from "triad". 20. Pingback: Top Posts << WordPress.com 21. [3352] Pseudonym says: 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. + [c883] slacker says: April 4, 2014 at 10:32 pm I realize it's been 5 years... but for the benefit of new readers: You got the etymology of at least the "bus" wrong. "Bus" was taken from the old electrical engineering concept of a "busbar", i.e. a solid rod or strip of metal meant to conduct very large currents and distribute power to multiple receivers attached to it. "Busbar" itself is a contraction of "omnibus bar", "omnibus" being Latin for "to all" o [phot] Jason Feingold says: April 23, 2014 at 12:57 am And the English word 'bus' (as in transport) is also derived from 'omnibus'. 22. [1255] Jenny says: 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? + [1701] Captain Oblivious says: 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. o [563b] Todd Trimble says: December 30, 2012 at 9:15 am That's an invented etymology (of the *mathematical* term "monad") if I ever saw one. Much more likely, I believe, is that it's a back-formation from "monoid", a closely related concept. # [f8ad] Graham Wideman says: February 27, 2013 at 6:08 am You guys might be interested in my "etymology" thread at stackoverflow. http://stackoverflow.com/questions/ 14090183/haskell-monad-etymology-versus-meaning 23. [7023] Mikael Vejdemo Johansson says: 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.... 24. [1255] Jenny says: 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. 25. [de5d] Phil says: 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... 26. Pingback: The Real Adam - Monads + Ruby = crazy 27. Pingback: On keeping category theory and abstract algebra alive in Haskell << Integer Overflow 28. [3352] Pseudonym says: January 17, 2009 at 8:50 pm I'm not scared, are you? 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. 29. [7023] Mikael Vejdemo Johansson says: 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. 30. Pingback: Fad diets are like burrito tutorials << blog :: Brent -> [String] 31. Pingback: a chicken monad << blog :: Brent -> [String] 32. [0d40] Michael Easter says: 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 ;-) 33. [0d40] Michael Easter says: 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. 34. [0d40] Michael Easter says: March 8, 2009 at 1:34 am http://twitpic.com/1xavz 35. [9eb7] Curt Sampson says: 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 36. [91aa] Cory says: 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... 37. [b401] marcio says: 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... 38. Pingback: Understanding monads << The Lumber Room 39. [711d] inhahe says: December 10, 2009 at 11:30 pm ok, so are you going to write a tutorial on monads for us? ;P (or have you already?) 40. [f8cc] Ramkumar Ramachandra says: December 11, 2009 at 5:18 am Good post. Everyone is used to a certain level of abstraction, and this heightens with learning. While not going to the extent of teaching group theory to a small kindergarden kid, one should also be careful to avoid hard-coding patterns into students. Hardcoding patterns using examples inhibits further learning. + [22c9] Eric says: April 26, 2011 at 7:16 pm I disagree. Abstractions should be learned bottom up by having students experience several "different in the specifics" examples which also have a commonality, and questioning/challenging them to discover what is common among the examples. Only then can you hope to give a simple expression for the essence of the abstraction and hope that it be understood. 41. [aa10] wonk says: December 15, 2009 at 1:21 pm Mark-Jason Dominus has now proven that monads actually are like burritos. + [cc11] Brent says: December 15, 2009 at 2:38 pm Actually--and this is an important distinction--he has only proven that burritos are monads. =) 42. [9599] Malcolm Gorman says: December 16, 2009 at 12:13 am I agree. I like BOTH concrete AND abstract attributes in a learning context. And that includes source code comments. What's the best monad tutorial providing both? Mal. + [cc11] Brent says: December 28, 2009 at 5:14 pm I'm a bit biased, of course, but I recommend starting with the Typeclassopedia and then proceeding to follow up some of the citations if desired. 43. [cb27] Andrew Winkler says: December 18, 2009 at 7:56 pm If you've got a mathematical background, then think of a monad as any kind of completion. The real numbers as a completion of the rationals under order, the algebraic closure of a field, the cauchy sequences as a completion of a metric space, etc. Any object can be embedded in its completion. That's return. Any object, completed twice, is the same completion. That's join. Maps among the objects extend to mappings among the completions. That's fmap. If your mathematical background is stronger, "completion" translates to "adjoint functors", and monads are an essentially equivalent way of describing adjoint functors. + [22c9] Eric says: April 26, 2011 at 7:23 pm Perhaps part of the problem here is that words like bind join and return all have long-established meanings in the world of computer programming (join actually has two such meanings, one in concurrent programming and one in relational database querying). Now correct me if I'm wrong but hasn't the monad stuff given completely different meanings (from the familiar-to-programmer meanings) in just about every sense to all three of these words, Now that seems, to an experienced programmer, as just gratuitously mean, and ill-considered, when defining a relatively new PROGRAMMING concept. o [f8ad] Graham Wideman says: February 27, 2013 at 6:28 am ... not to mention type, class and instance all referring to concepts that don't align well with their meanings in other languages. # [3352] decourse says: January 14, 2014 at 9:20 pm This is a year later, so sorry for the late contribution, but "class" is one of the few words that does align well with its meaning in mathematics. The term "class" comes to us straight from Goedel-von Neumann-Bernays set theory. To overcome Russell's Paradox, they re-axiomatised set theory so that a set is any well-behaved collection of "things", but collections which aren't so well-behaved (e.g. "the set of all sets") is a "class". Similarly, in programming languages, a "type" is a set/collection of values, and a "class" is a set/ collection of types (i.e. a "set of sets"). The confusion, I think, is that when you write the word "class Foo" in many programming languages, you're actually doing three distinct things: You are declaring a new type called "Foo", and you are declaring a new collection of types also called "Foo", and you are declaring that the type "Foo" is a member of the collection "Foo". In Haskell, those three distinct things are separated out, which makes for more typing, but also more clarity. 44. Pingback: Linktipps Januar 2010 :: Blackflash 45. Pingback: Tab Sweep: Monads 46. Pingback: Garbled >> Blog Archive >> Git Tutorials Suck, A Sucky Git Tutorial 47. [3282] Jan Snajder says: September 19, 2010 at 5:53 am Very good post, thank you! From my experience, getting to understand monads (or any abstract notion for that matter) is about developing an intuition about when and why they might be useful. This intuition has to be developed gradually on a series of examples. Only if I can see a pattern there, will I be willing to move to a more abstract level, otherwise I won't bother. Burrito analogies are useful, but only as a sort of private post hoc explanations. 48. Pingback: intelligence about intelligence << Truth of the Lesser Men 49. [8191] nothingmuch says: January 11, 2011 at 2:16 pm Feynman put it very well: http://www.youtube.com/watch?v= Cj4y0EUlU-Y 50. [1822] gvaerg says: February 11, 2011 at 11:09 am I finally understood monads today! (It was through the equivalence of bind with fmap/join that I got it.) Moreover, I thought immediately of this blog post that I have read months ago and I also understood why monads are like burritos. Thank you for this treat! 51. [7dfa] Lance Walton says: February 17, 2011 at 5:48 pm Two good introductions to monads: * Yet Another Haskell Tutorial builds it up nicely (chapters 5 and 9 I think): http://www.cs.utah.edu/~hal/docs/daume02yaht.pdf * Daniel Spiewak's blog: http://www.codecommit.com/blog/ruby/ monads-are-not-metaphors + [f8ad] Graham Wideman says: February 27, 2013 at 6:34 am Yet another newer link: http://en.wikibooks.org/wiki/Haskell/ YAHT 52. [fb6f] raving1 says: September 22, 2011 at 9:58 am "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 ...." You describe ... ... Fallacy! Fallacy! |-> ... indicates 'Tautology' 'Tautology' = 'Object' <- Curry's paradox, Haskell Fallacy!, 'Tautology', 'Object' = DESCRIPTION "...implications for pedagogy. The heart of the matter is that people begin with the concrete ..." No. "...implications for pedagogy" 'Gradient of descent' for convergence] -------- "If you ever find yourself frustrated and astounded that someone else does not grasp a concept..." There are other reasons. Your 'monad tutorial fallacy' is excellent! ... A fundamental reason is 'Subject(ivity)' [Closed DESCRIPTION] 'Subject(ivity)' and DESCRIPTION can be extended to 'OPEN DESCRIPTION' but it is difficult (to describe) and the working-of-the-process is described by your use of 'Intuition'. 'Subject(ivity)' can be a timely activity involving the 'over-arching' span of islands of discontinuity. A SINGLE 'subjective experience' is but a moment's instantaneous (and temporally slurred) glimpsed experience and realization of reality. DESCRIPTIONS can be formed by aggregating many 'SINGLE momentary subjective experiences' (DESCRIPTIONs) -------- Nice to find people who have a passion for categorization! It's a lonely world of understanding but not being understood.. ... 53. Pingback: xion.log >> Adventures in Haskelland 54. Pingback: We have no idea what we are doing: exclusion in free software culture << Alex McLean 55. Pingback: Monads: Easy or Hard? | blog :: Brent -> [String] 56. [e8aa] Alberto Gomez Corona says: August 18, 2012 at 4:53 am What you say is a disgrace of the whole educational system since at least the Enlightenment and the Age of Reason. It is derived from a wrong idea of the mind: the idea that it is a unique monolitical rational processing unit, instead of a collection of specialized modules. One of these modules is the one in charge of learning by example. The alumni have to repeat the process of discovery from examples to generality. If this is not provided by the teacher, the teacher is not a teacher but a "enlightened" rationalist exhibitionist. + [c883] slacker says: April 4, 2014 at 11:37 pm That's exactly why I call this era "Endarkenment". 57. [pict] Yang Jerng Hwa says: October 5, 2012 at 8:10 am Totally agree. My own thinking about this has previously led me to believe that artificial intelligence code should be architectured in this way. #2cents 58. [f8ad] Graham Wideman says: February 27, 2013 at 6:24 am I agree with the diagnosis: "failing to recognize the critical role that struggling through fundamental details plays in the building of intuition". But I'll claim that the solution isn't to force people to go through their own hours/days/weeks of wandering in the wilderness in the hopes of stumbling on the missing jigsaw pieces. It's to spell out the fundamental details properly, and leave no series of dots unconnected. The (well at least _a_) reason this is a particular problem in Haskell monads is that Haskell's treatment of monads, and the resulting syntax, is designed to _hide_ the details so as to be left with only a "beautiful" version of the mainline code that expresses the "main intent" (for some value of "intent"). All the stuff that is elided (or hidden under multiple layers of type substitution, syntactic sugar etc) in achieving that concision is the stuff that the beginner needs decompressed in order to know to see how it works. See the reader comments inline in Real World Haskell's online version for copious examples of crucial dots not joined, and that book is a relatively carefully prepared one! 59. Pingback: My take on monads | The Pleasure of Trying Things Out 60. [9144] Adrian May says: March 18, 2013 at 10:37 pm It's an interesting thought but I think the problem is not with abstractions in general, but whether or not those abstractions are already familiar to the reader. In the case of monads, people using the examples-first approach usually start with boxes, but that just stores up problems for later. I think of monads as glue code. That's a pretty general abstraction that every C programmer knows about - we've all been bored by writing chains of pedantic error handlers and logging mantras. One can suggest that if you have a mechanism for factoring out the glue from the blocks, then you might try to design all the blocks to be compatible with one type of glue. Then you can work through the parser, state, etc, monads, always emphasising that they are examples of what we said at the outset: glue. This approach also avoids the pitfall of people thinking more monads make a better program, just as OO newbies write millions of classes to earn brownie points. Often a simple applicative functor is all the glue you need. 61. [6328] ben says: July 9, 2013 at 2:44 am I think part of what you're saying is that monad tutorials are written for the writer and not the reader : someone has an a-hah moment and they want to share it, but what they are sharing is their a-ha moment and not knowledge, or the process of acquiring knowledge. My favorite book ever in all of my math studies is Atiyah and MacDonald's Commutative Algebra. It's basically a big list of exercises and just enough definitions and theorems to get you through them. It's remarkably short and remarkably easy to learn from, and a lot of the most interesting stuff is developed in the exercises. Instead of writing endless beautiful explanations, they just give the reader the tools to figure it out for themselves. It's a masterpiece. Perhaps someone should write the monad tutorial in this style -- a series of exercises. (Perhaps someone already has.) + [cc11] Brent says: July 9, 2013 at 7:51 am Hmm, that's a really good idea! + [56cc] Josh Graham (@delitescere) says: May 13, 2014 at 10:58 pm Suggested a while ago... https://byorgey.wordpress.com/2009/01/ 12/abstraction-intuition-and-the-monad-tutorial-fallacy/# comment-1025 62. Pingback: The Monad Tutorial Fallacy | Ted Goranson's ISIS-US Blog 63. Pingback: A collection of monad tutorials and a few other miscellaneous things. | BrokeTheBuild 64. Pingback: Figuring out the State Monad | SAdams in Kent 65. Pingback: Monads are hard because ... | The Endeavour 66. Pingback: What are monads and why are they useful? | The Pleasure Of Finding Things Out 67. Pingback: My Math Diary 68. [67f5] Abstractor says: July 14, 2014 at 4:44 pm Very insightful article which went from teaching the "monad tutorial fallacy" to the more abstract "tutorial fallacy". Thank you. 69. [2865] Brad C. says: August 20, 2014 at 4:31 pm Hi Brent. I'm not a Haskell programmer, but I found your insight that "people begin with the concrete, and move to the abstract" to be very fascinating. Would you mind elaborating on that-how you came to that conclusion? I'm interested in regards to other contexts, namely compassion, suffering, and group identity. Thanks! + [9eb7] Curt Sampson says: August 20, 2014 at 10:16 pm That learners start with the concrete and move to the abstract is actually and old and quite well-known idea in the field of learning. Start by looking in to the Dreyfus model of skill acquisition (the Wikipedia article on this is a good starting point) and you'll find plenty of places to follow up from there. The best book I've read on the model is the Patricia Benner book mentioned in the references in that article. (Even though it's about nursing, I found it extremely applicable to software development as there seem to be many similar skills and learning situations involved; it's a book that I think that all software developers should read.) 70. Pingback: Types will carry you over the Monads | Funkcionalne.cz 71. Pingback: Monads are like burritos | kewl beans 72. Pingback: How to: What is a monad? | SevenNet 73. Pingback: Solution: What is a monad? #dev #it #computers | Technical information for you 74. Pingback: Fixed What is a monad? #dev #it #asnwer | Good Answer 75. Pingback: Teaching How to Learn | SuperGinBaby 76. Pingback: Haskell monads for C++ programmers | Atila on Code 77. [3c24] Silent Wiggler says: January 26, 2015 at 10:17 pm This is very interesting, because I was reading, and I couldn't help but think of the "monad tutorial fallacy" when I discovered that this same phenomenon was documented as early as 2004 (but probably way earlier, of course!) Seriously, take a look at "What Makes an Insight Problem? The Roles of Heuristics, Goal Conception, and Solution Recoding in Knowledge-Lean Problems". 78. [4557] sy2m says: February 13, 2015 at 8:15 pm Reblogged this on A Student Forever and commented: Reading my calculus textbook, wondering why it's so hard to understand, and came across this wonderful article explaining the whole phenomenon with a clear analogy. 79. Pingback: Monads | Vinipsmaker labs 80. Pingback: What The Heck Is A Monad | Khanlou.com 81. [375e] tomtubbs says: October 10, 2015 at 4:02 pm Do you have recommendations for any good beginner articles on monads? + [cc11] Brent says: October 11, 2015 at 9:42 am I am a bit biased of course, but I recommend reading the Typeclassopedia: https://wiki.haskell.org/Typeclassopedia . The "further reading" section also has links to other good articles and tutorials. o [7dfa] Lance Walton says: October 11, 2015 at 12:49 pm I have a great metaphor for beginner tutorials on monads. Seriously: http://www.codecommit.com/blog/ruby/ monads-are-not-metaphors > 82. Pingback: Un tutorial de monadas - la monada Maybe | Blog de Francisco Nebrera 83. Pingback: Can anyone explain Monads? [duplicate] - ASK AND ANSWER 84. Pingback: What is a monad? - ASK AND ANSWER 85. Pingback: December Links and Activities | Mental Wilderness 86. Pingback: What the heck is a Monad? - Haiku Robot 87. Pingback: Monads are still f'ed up, but good? | Hey There Buddo! 88. [ff44] davidwlocke says: July 1, 2016 at 12:22 pm This abstraction process is exactly what made requirements elicitation impossible. To the users, their work looks like a burrito, but they went through the agony of making that so, and quickly forgot the agony, never to recall it again. When asked by developers, users give them the burrito story, not the agony story. So the resulting code never really matches the user's conceptual model of what they are doing. Observe, ask, but to know is to agonize. 89. Pingback: Abstraction, intuition, and the "monad tutorial fallacy" - Monads 90. Pingback: Obligatory Monad Post - Mansour Ahmed 91. Pingback: ListdeYou bu | Qing Ying Yi Shu Da Xue robotsutoJi Shu Yan Jiu Hui 92. Pingback: How I learned to program | Digitators 93. Pingback: Gym Experiments: CartPole with DQN | voyage in tech 94. Pingback: Squeezing More Out of the F# Type System - Introducing Crates - G-Research 95. Pingback: Monoidal sparks | blog :: Brent -> [String] 96. Pingback: Why You'll Probably Never Use Haskell in Production | henrydangprg 97. Pingback: Monads as a Programming Pattern - Viral Cruncher 98. Pingback: Resumen de lecturas compartidas durante agosto de 2019 | Vestigium 99. Pingback: The Pain Points of Haskell: A Practical Summary - NSO News 100. Pingback: The Pain Points of Haskell: A Practical Summary 101. Pingback: To be or not to be? Maybe! Optional values in C++17 - Hackshots Comments are closed. * Pages + About me + BlogLiterately + Catsters guide + How to print things * Categories Categories[Select Category ] * + AC + algorithm + announcement + applicative + art + axiom of choice + balanced + Beeminder + bijection + BlogLiterately + category + challenge + collaborative editing + combinatorial species + combinatorics + competitive + constructive + contest + darcs + data + design + diagrams + dissertation + drawing + DSL + EDSL + enumeration + feedback + functional + functional programming + functor + game + geometry + GHC + ghci + graphics + hackathon + Hac ph + haskell + ICFP + isomorphism + Kattis + library + log + monad + monads + monoid + multiset + music + paper + parsing + partitions + patch theory + pedagogy + Philadelphia + pictures + productivity + programming + QuickCheck + random + release + sampling + sets + species + talk + teaching + theory + translation + tree + tutorial + type-level + Typeclassopedia + types + virtual + workshop * Archives + September 2021 (5) + August 2021 (1) + June 2021 (3) + February 2021 (1) + July 2020 (2) + June 2020 (3) + May 2020 (4) + April 2020 (2) + March 2020 (2) + February 2020 (4) + December 2019 (1) + November 2019 (1) + October 2019 (1) + July 2019 (1) + May 2019 (2) + April 2019 (2) + March 2019 (1) + February 2019 (3) + November 2018 (1) + October 2018 (3) + June 2018 (1) + May 2018 (4) + April 2018 (1) + March 2018 (2) + February 2018 (3) + January 2018 (1) + November 2017 (1) + September 2017 (1) + June 2017 (1) + May 2017 (1) + April 2017 (1) + March 2017 (1) + February 2017 (4) + January 2017 (3) + November 2016 (2) + October 2016 (2) + September 2016 (3) + August 2016 (4) + July 2016 (1) + June 2016 (1) + May 2016 (3) + April 2016 (2) + March 2016 (3) + February 2016 (1) + November 2015 (2) + October 2015 (1) + August 2015 (2) + July 2015 (1) + June 2015 (3) + May 2015 (2) + April 2015 (1) + March 2015 (1) + August 2014 (3) + June 2014 (2) + May 2014 (2) + January 2014 (2) + October 2013 (1) + August 2013 (1) + July 2013 (1) + May 2013 (1) + April 2013 (3) + March 2013 (2) + January 2013 (2) + December 2012 (2) + November 2012 (4) + October 2012 (3) + August 2012 (4) + July 2012 (5) + June 2012 (1) + March 2012 (1) + January 2012 (1) + November 2011 (4) + October 2011 (3) + September 2011 (2) + August 2011 (2) + July 2011 (2) + June 2011 (1) + May 2011 (6) + April 2011 (2) + March 2011 (1) + February 2011 (3) + January 2011 (1) + December 2010 (2) + November 2010 (3) + October 2010 (1) + September 2010 (1) + August 2010 (3) + July 2010 (2) + June 2010 (3) + May 2010 (3) + April 2010 (3) + March 2010 (2) + February 2010 (1) + January 2010 (1) + December 2009 (2) + October 2009 (3) + September 2009 (2) + August 2009 (4) + July 2009 (7) + June 2009 (1) + May 2009 (2) + April 2009 (1) + March 2009 (2) + February 2009 (3) + January 2009 (3) + December 2008 (2) + September 2008 (2) + August 2008 (1) + July 2008 (3) + June 2008 (1) + April 2008 (4) + March 2008 (4) + February 2008 (4) + January 2008 (2) + December 2007 (4) + October 2007 (2) + September 2007 (2) + August 2007 (3) + June 2007 (2) * Top Posts + Abstraction, intuition, and the "monad tutorial fallacy" + Swarm: preview and call for collaboration + Types versus sets in math and programming languages * Blogroll + a neighborhood of infinity + Good Math, Bad Math + Lambda the Ultimate + Planet Haskell + The Monad.Reader + The Unapologetic Mathematician + The Universe of Discourse * Fun + Daisy Owl + Dinosaur Comics + Hark, a vagrant! + indexed + Order of the Stick + Savage Chickens + xkcd * Personal + del.icio.us + Library + Photos + The Math Less Traveled * Meta + Register + Log in + Entries feed + Comments feed + WordPress.com blog :: Brent -> [String] Blog at WordPress.com. Send to Email Address [ ] Your Name [ ] Your Email Address [ ] [ ] loading [Send Email] Cancel Post was not sent - check your email addresses! Email check failed, please try again Sorry, your blog cannot share posts by email. [Close and accept] Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use. To find out more, including how to control cookies, see here: Cookie Policy [b]