SKC> This entire discussion is about 'breaking a cyclic graph of conceptual SKC> dependencies'. Unfortunately, I don't think it can be done well in short SKC> amount of time. I bet if we sat down and listed all the concepts required to write idiomatic Haskell (even idiomatic Haskell 98 (whatever this means)), to write programs that do the things that we all have done in other languages (you know what I'm talking about here, but of course this is up for debate too), we would see that it was not a linear structure but a cyclic graph or at best a tree of concepts: we need to understand higher order functions, polymorphic higher order types for monads, monads to understand I/O really well (or to understand WHY I/O in a purely functional language is the way it is), typeclasses, laziness, etc. etc. In a lot of situations, pedagogy is hard to 'linearize'. Why would it be any different in programming? especially in Haskell? A lot of learning Haskell is just helping reinforce this strong, but sometimes subtle "base of knowledge" required to really start to "get" Haskell. [1] HT> Btw. Simon Thompson states in his book, that he found it didactically HT> infelicitous to introduce recursion before higher order functions because HT> that let beginners stick to case discriminations and recursive programming HT> instead of taking advantage of functions like 'map', 'iterate', 'fold' HT> etc. I can confirm this experience and I think that it is similar to IO HT> vs. non-IO. It very well may be "didactically infelicitous" [2]. (I wish there were some program we can just run on a course syllabus and find out that something is "felicitous"):
conceptsInHaskell :: [haskellConcept] conceptsInHaskell = [...] -- abstract main = print $ sort conceptsInHaskell .. error: haskellConcept not a member of class Ord.
Maybe we'll (collectively) get better and better at this. I think we are. Hopefully experience and sharing this information will be beneficial to all (as well as discussion like these). Maybe it depends on who is learning Haskell, and why: maybe the 'conflict' is that "learning to program *in* Haskell" /= "learning to program *with* Haskell." But maybe it's not ultimately an optimizable piece of data, the "right" order of teaching concepts in Haskell. Maybe it should be allowed to be more random-access? (I personally like things more that way :-) . Cheers Jared. -- jupdike@gmail.com http://www.updike.org/~jared/ reverse ")-:" [1] Perhaps a point in Haskell's favor for pedagogy is that there are things you can do in Haskell that you just can't do (in the same, succint sense) in most programming languages, e.g. even OCaml. Maybe these things (and they are neat, simple things, like the code ""twos = 2:twos"" and then manipulating this infinite stream) can help motivate people to really want to grok Haskell, and to stick with it and use it for practical projects because of its many advantages. :-) [2] Paul Hudak does this in the Haskell School of Expression. He writes recursive code with cases, etc. and then in a later chapter explains how to rewrite it with map, fold, etc. Fine. It takes steps to learn how to write idiomatic Haskell. At least for me, the joy of Haskell is not in "memorizing vocabulary" (as is common in a language like Java, or C#) but rather, internalizing concepts. By writing ugly code at first and then seeing the patterns and refactoring with map and fold, I've personally internalized it (instead of learning some clever rule, up front, that I'll later forget). Think Why FP Matters by Hughes. He does this too (recursion, pattern matching, then later swapping in higher order functions), to explain why FP is so great.