I think his choice of Monads to explain this phenomenon was a good one, speaking as someone who does not understand Monads but occasionally glances at tutorials about them.<p>My thought process about those tutorials is always "explain to me why I should care." I get that the problem that Monads try to solve is that functional programming demands that a function always return the same value given the same arguments, and that makes I/O impossible, but you can't write real programs without I/O. So Monads are an attempt to find a loophole.<p>Well, what if the answer is just that functional programming is just not a good way to write programs in the first place? Sure, functional programming has lots of properties that are appealing, but if you need to do intense mental gymnastics just to get "print 'Hello World'" is it actually worth it?<p>To me, that is the point from which a "Monad tutorial" should begin, and then provide concrete examples showing that with Monads, sticking with functional programming is better than just giving up and using Python.
I like the explanation that the metaphor is only valuable if you have other stuff pre-loaded that it can sit on top of.<p>I think people learn different ways. This writer seems to approach the world in the way I do, but I'm not sure everyone is like that. I've had friends who can start of with the abstract and just suck it in. I think there's a correlation with people who can do this with those who can easily remember things 'for the test' at school even if they can't put the knowledge into context.<p>I've never discovered how to tweak my brain to get it to buffer knowledge like this with a faith that it will be useful in a minute - I find it exhausting and I still don't retain.<p>I sat down to write a program in iolanguage the other day. Even though I've read lots of tutorials and feel like I know it now, it was very exhausting to connect that with a practice of do this, now do that, etc. I remember a similar feeling when I started java which I overcame by writing a program a day that started off with static void main(String args[]).<p>A big hurdle with conceptual ideas is getting your brain to twist the right way around to them when you encounter a problem that could be solved by them. I think this is the difference between raw knowledge and what Heinlein used the word 'groking' to describe.<p>One game that sometimes works as an alternative is to example-based learning something through a context of documenting it. This can be difficult though if the barrier between this knowledge and other topics isn't well-defined.
The problem with monads in Haskell is a chicken-and-egg problem. When an ordinary programmer (as oppossed to a mathmatician) starts toying with a new language, they usually start with some simple IO code (starting from "hello world") and play and explore their way deeper into the language. In Haskell, however, you don't get much further than "hello world" before you bang your head against the IO monad. Hence the monad totorials aimed at newbies. The problem is that to understand monads you have to understand a lot of other advanced Haskell features like type constructors, type classes, type inference, partial functions and so on.<p>I think the solution is to realize that you dont need to understand monads to write IO code, you just need to understand the rules of do-notation. Sure, do-notation is implemented using monads under the hood, but you dont need to understand monads to use it, just as you dont need to understand vtables to use objects.<p>I should propably write a do-notation tutorial to show how far you can get without understanding monads.
This is the sort of thing that hypertext should be good at. You write a page explaining how to use monads for IO, a page explaining the list monad, a page for the Maybe monad, blah blah blah, and a page explaining the Monad typeclass (probably another page explaining do-notation too). And they all link to each other as appropriate.
Analogies are not very helpful for learning or explaining monads. The more you try to anchor the idea to something you already know, the further away you understanding what's going on.<p>I think that when teaching or learning monads the concept to focus on is composing smaller units (computations) into larger ones (aggregate computations), often by passing the output from one computation into the next one. It's also important to understand that once you have composed several small computations into a large computation you do not care or necessarily even know that the large computation is composed of smaller ones.<p>After meditating on that idea for a while it's necessary to see many different examples of useful monads. The 'All About Monads' tutorial (probably the best monad tutorial) has a section which is all examples. You need to see as many examples as possible because you can't understand monads by looking at a single specimen.<p>Monads are an abstract generality which provides a similar structure to many different things that you would never have expected to have much in common. Without understanding that commonality, you're missing the point and monads will remain incomprehensible.
I was hoping the "monad tutorial fallacy" would be something related to assuming people cared about monad tutorials. Oh well - I will eagerly await that article ;-)