On 14/08/07, Lanny Ripple <[EMAIL PROTECTED]> wrote: > Having just gone through all the tutorials and things (again but > this time I think it stuck) the Haskell community is on the wrong > track as far as teaching Monads to new programmers. > > If I were teaching addition and multiplication to children I > wouldn't start with, "We'll begin by defining an algebraic > structure named a "Group". From there we'll expand our concept > to a "Ring" and "Field". A group is a set and a binary operator > usually named "+" (or sometimes "*") such that...". > > No no no. You start with, "You all know how to count from one to > 10. If we have 1 item and we 'add' another 1 item we have 2 > items. We write this 1+1=2." > > The tutorials seriously need to step back and start with > something like, "To enforce order of evaluation we evaluate > closures* returning a defined type. The first closure will feed > its result to the second which will in turn feed it's result to > the third. Since the third closure can't be evaluated without > having the results from the second and first (and thus they had > to be evaluated earlier in time) we get a defined evaluation > sequence. Here are some examples..." > > (* Even using the word 'closure' is scary for those not familiar > with them.) > > Then, like "Monads For Functional Programming" (the paper that > finally clicked Monads for me) you point out that evaluating all > these closures returning a defined type in various ways form a > structure (which you can then explain) and we can use that > structure and change out the underlying effect(s) as needed. > > Now of course if your new programmer has the the necessary > background you can throw them in the deep end. But don't do that > to someone coming at the language from something like Java > learned out of a business degree course. (My background is a CS > degree with math minor and it still took two go-s at Haskell > before I got as far as understanding what folks were talking > about with Monads. Wish I had found Wadler's MFFP the first time > around.) Where are the shallow end tutorials? (Don't get me > wrong. The tutorials are good but there is also a place for the > "learn-by-rote with lots of examples" ones too.)
Agreed, people tend to complicate things in the interest of being precise, which is probably a misstake when dealing with non-mathematicians. I like the very light weight analogy (which works for most practical uses of monads) that a monadic action is a "recipe" (you can even say that they're stored in sealed envelopes to model the opaqueness of e.g. IO). You can store recipes in boxes (data structures), pass them around, combine them to make new recipes etc. That's an abstraction of "actions" that everyone is familiar with. The analogy might not fit everything perfectly, but at least the reader will be with you from the start, and that makes it more likely that they'll follow you when you start diverging from the metaphor. Then you say that the GHC runtime system is the cook, who will take the "main" recipe and follow it. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
