Abstraction, intuition, and the “monad tutorial fallacy” | Hacker News Reader

Abstraction, intuition, and the “monad tutorial fallacy”

byorgey.wordpress.com

47 pointsjlhamilton11 comments

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.

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.

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?

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.

IO handling is just one of the uses of monads in Haskell. List comprehensions (like in Python) are another use. They are also used for parsers, asynchronous programming, exception handling and continuations.

I wrote a answer on stackoverflow which tries to explain monads with some practical examples: http://stackoverflow.com/questions/44965/what-is-a-monad#194...

That was very good! Nice examples.

You also do a good job summarizing why IO is hard in Haskell, in that you need to understand a lot about the language to understand how IO works. I guess it's up to the individual to decide whether FP is worth getting past that initial hump.

I found the way Clean deals with IO simpler to learn than Haskell's Monads. (But then, I learned Clean before I learned Haskell. They have a nice Jump-n-Run in their example directory.)

Clean employs linear logic, that is you can only have one copy of the 'World' in your program. Look at the printing function as an example: It takes your old World and transforms it into a new World, that has something printed to the screen.

Of course such a view of the outside world is quite autistic. But it works as long as you manage to have only one World around in your program.

The IO Monad in Haskell could have been implemented with linear logic. (And in GHC it is, I think.)

More information at http://homepages.inf.ed.ac.uk/wadler/papers/monadsdeclare/mo...

The original papers are surprisingly accessible. I prefer them to the tutorials.

I like the explanation that the metaphor is only valuable if you have other stuff pre-loaded that it can sit on top of.

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.

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.

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[]).

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.

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.

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.

I should propably write a do-notation tutorial to show how far you can get without understanding monads.

Do that. (No pun intended.)

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.

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.

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.

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 ;-)

I often fail to provide enough examples when explaining my intuitions to others.

Reply on news.ycombinator.com