Glad to hear a teacher-pov Richard!
On Thu, Feb 11, 2016 at 5:32 AM, Richard A. O'Keefe
Just as a thought experiment: The FTP had a landslide support on the
libraries list. How would it have fared on a Haskell-Edu list?
Judging by the list of changes at https://wiki.haskell.org/Foldable_Traversable_In_Prelude the changes were mostly some extra classes (Monoid, Foldable, Traverseable) showing up in Prelude and a bunch of type changes to functions: ... [x] ... changing to (Foldable t) => ... t x ... ... [x] ... changing to (Traverseable t) => ... t x ...
This is actually quite an interesting change. Using the same names *consistently* across a wide range of types makes programs easier to write and easier to read. From an educational point of view, you can't say
"We didn't need the Prelude to write `all` for us. We could have written
all p (x:xs) = p x && all p xs all _ [] = True "
any more because that has the wrong (old, list-specific) type. You *can* say
"We could have written
all = foldr True (&&) "
So you lose a lesson that comes somewhere near the beginning, when you are still trying to get across the idea of higher order functions and lazy evaluation, and gain a lesson that comes much later, about the power that typeclasses add to composition. Come to think of it, you could use this to motivate typeclasses.
I think you could build *just as good* an introductory Haskell course on the post-FTP libraries as you could on the pre-FTP libraries, but it would be a *different* course.
I think this is a good framing of the question Lets say you take the subject matter for the introductory programming course. And you topsort it along prerequisites; ie topic A precedes topic B if understanding B needs knowledge of A So is the structure/topography of the language Haskell conformant with this topsort? Or does one need to jump against the ordering at times? As example, take a course using C to teach programming. And consider input vs pointers. You have one of 3 choices: 1. Pointers before input -- you probably know programming earlier! 2. Input before pointers -- use getchar not scanf and laboriously write atoi etc before anything else -- classic K&R 3. Bardur's solution -- "just ignore that bit (the '&') , I'll explain when you're ready" For a one-off case that's ok; when it happens at every turn teaching/learning becomes a nightmare The C version of that is described in this old paper: C in education and software engineering http://blog.languager.org/2013/02/c-in-education-and-software-engineering.ht... I just hope Haskell does not repeat that history -- especially considering that this whole discussion starts with the need to distinguish pointer-types and non-pointer types