[Haskell-cafe] Re: Tutorial uploaded

[Jared Updike]

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 at 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.