<div dir="ltr">Glad to hear a teacher-pov Richard!<br><div><div class="gmail_extra"><br><div>On Thu, Feb 11, 2016 at 5:32 AM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Just as a thought experiment: The FTP had a landslide support on the libraries list.<br>
How would it have fared on a Haskell-Edu list?<br>
</blockquote>
<br></span>
Judging by the list of changes at <a href="https://wiki.haskell.org/Foldable_Traversable_In_Prelude" rel="noreferrer" target="_blank">https://wiki.haskell.org/Foldable_Traversable_In_Prelude</a><br>
the changes were mostly some extra classes (Monoid, Foldable, Traverseable) showing up<br>
in Prelude and a bunch of type changes to functions:<br>
... [x] ...   changing to (Foldable t) => ... t x ...<br>
... [x] ...   changing to (Traverseable t) => ... t x ...<br>
<br>
This is actually quite an interesting change.<br>
Using the same names *consistently* across a wide range of types<br>
makes programs easier to write and easier to read.<br>
>From an educational point of view, you can't say<br>
<br>
  "We didn't need the Prelude to write `all` for us.<br>
   We could have written<br>
<br>
    all p (x:xs) = p x && all p xs<br>
    all _ [] = True<br>
  "<br>
<br>
any more because that has the wrong (old, list-specific) type.<br>
You *can* say<br>
<br>
   "We could have written<br>
<br>
    all = foldr True (&&)<br>
  "<br>
<br>
So you lose a lesson that comes somewhere near the beginning,<br>
when you are still trying to get across the idea of higher order<br>
functions and lazy evaluation, and gain a lesson that comes<br>
much later, about the power that typeclasses add to composition.<br>
Come to think of it, you could use this to motivate typeclasses.<br>
<br>
I think you could build *just as good* an introductory Haskell<br>
course on the post-FTP libraries as you could on the pre-FTP<br>
libraries, but it would be a *different* course.<br></blockquote><div><br></div><div>I think this is a good framing of the question<br></div><div>Lets say you take the subject matter for the introductory programming course.<br></div><div>And you topsort it along prerequisites; ie topic A precedes topic B if understanding B needs knowledge of A<br></div><div>So is the structure/topography of the language Haskell conformant with this topsort? Or does one need to jump against the ordering at times?<br><br></div><div>As example, take a course using C to teach programming. And consider input vs pointers.<br></div><div>You have one of 3 choices:<br></div><div>1. Pointers before input -- you probably know programming earlier!<br></div><div>2. Input before pointers -- use getchar not scanf and laboriously write atoi etc before anything else -- classic K&R<br></div><div>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<br></div><div>The C version of that is described in this old paper: <a href="http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html" target="_blank">C in education and software engineering</a><br><br></div>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<br></div>
</div></div></div>