Re: [Haskell] Another First course in Haskell
Piyush P Kurur wrote: ( http://article.gmane.org/gmane.comp.lang.haskell.general/16390 )
I am planing a haskell based functional programming course. It is supposed to be a first course and I intend to show how real world applications can be built quite easily in haskell.
Any feed back is really welcome.
Is it a first course in programming, or in functional programming? Either way, I recommend focus on "data" and then "class/instance", i.e. have the students use algebraic data types right from the beginning (*). Another idea for teaching is to introduce the language by having the students use standard libraries (e.g. Data.Map), also right from the start. So they are forced to read type signatures etc. (**) (*) that's the main problem I see with Hutton's book http://www.cs.nott.ac.uk/~gmh/book.html : it has "Declaring types and classes" as chapter 10 (of 13 total). I think that's way off - and it leaves readers (students) with the impression that declarative programming basically deals with (functions on) lists. This may have been true in the 70s/80s (LISP, Prolog), but it certainly shouldn't be true today. Recall the proverb "Get your data structures correct first, and the rest of the program will write itself." (David Jones, cited in John Bentley: More Programming Pearls) I think this is independent of language and paradigm. (**) again, Hutton's book does not contain a single "import" declaration in the programming examples (did not check fully, but got this impression while browsing). Yes , Data.* is not Standard Haskell(98) and that's probably why he avoided it but the result diametrically contradicts everyday programming experience where the typical application program (in any language) is just some glue between library functions that do 90 percent of the actual work. Sure, a student programmer must be able to write a stand-alone bubble/quick/mergesort but it is equally (if not more) important that he knows how to (1) find and (2) call a sorting routine in any given programming environment. (So, have your students use http://www.haskell.org/hoogle/ ) Best regards, J.W.
It seems to me we should condense this thread into a series of new entires on the "Haskell in Education" page? People seem to be doing new courses, and new kinds of courses, in Haskell, so reflecting that online is a good idea. http://haskell.org/haskellwiki/Haskell_in_education waldmann:
Piyush P Kurur wrote:
( http://article.gmane.org/gmane.comp.lang.haskell.general/16390 )
I am planing a haskell based functional programming course. It is supposed to be a first course and I intend to show how real world applications can be built quite easily in haskell.
Any feed back is really welcome.
Is it a first course in programming, or in functional programming?
On Sat, Aug 23, 2008 at 8:41 AM, Johannes Waldmann < waldmann@imn.htwk-leipzig.de> wrote:
(*) that's the main problem I see with Hutton's book http://www.cs.nott.ac.uk/~gmh/book.htmlhttp://www.cs.nott.ac.uk/%7Egmh/book.html: it has "Declaring types and classes" as chapter 10 (of 13 total). I think that's way off - and it leaves readers (students) with the impression that declarative programming basically deals with (functions on) lists. This may have been true in the 70s/80s (LISP, Prolog), but it certainly shouldn't be true today.
Recall the proverb "Get your data structures correct first, and the rest of the program will write itself." (David Jones, cited in John Bentley: More Programming Pearls) I think this is independent of language and paradigm.
If functions on lists isn't the thing, what is the thing? "Data structures" isn't a very satisfactory answer for a n00b like me, because it doesn't capture Haskell's distinctive. I've had this same sense, but in a vague newbie way. This also seems to reflect a growing dissatisfaction with the prelude. Back in the day lazy lists were the thing and the Prelude seems to largely reflect that. Now it's something else I can't possibly articulate. But I can definitely see it trying to replace a significant amount of prelude functionality. Witness that nobody loves strings anymore because ByteStrings are cooler. The stream/fusion lists are way cooler than the stock lists. etc. Or I have no idea what I'm talking about. -- Darrin
Darrin Thompson wrote:
If functions on lists isn't the thing, what is the thing? "Data structures" isn't a very satisfactory answer for a n00b like me, because it doesn't capture Haskell's distinctive. [...]
Well indeed you can (should) have problem-specific (algebraic) data types in any language. In Haskell it's just a "data" declaration, while in OO design they call it the "compositum" pattern (and need some hundred more lines to write it down). What is "distinctively Haskell"? The focus in teaching could be: (1) data abstraction (-> functions, -> higher order functions) (2) type abstraction (-> type constructors, polymorphism etc.) ... and of course all the benefits from abstraction (=> re-usability) and strong typing (=> safety). J.W.
Hi
(*) that's the main problem I see with Hutton's book http://www.cs.nott.ac.uk/~gmh/book.html : it has "Declaring types and classes" as chapter 10 (of 13 total). I think that's way off - and it leaves readers (students) with the impression that declarative programming basically deals with (functions on) lists. This may have been true in the 70s/80s (LISP, Prolog), but it certainly shouldn't be true today.
That book is about teaching Haskell, not advertising it. If I wanted to advertise how cool Haskell was, I probably wouldn't dwell on lists. But to learn Haskell, I spent the first few years doing either list processing or very simple algebraic data types, and I think it made me a better programmer as a result. If you want to program Haskell, get the basics sorted. Once you have sorted the basics of functional programming, you can move on to the Haskell specific bits. The course I learnt from at York left out things such as modules, type classes (beyond slight Eq/Ord signatures), monads, IO (other than interact) and anything not in Haskell 98. What it did cover very well was functional programming and functional reasoning. Thanks Neil
That book is about teaching Haskell, not advertising it. If I wanted to advertise how cool Haskell was, I probably wouldn't dwell on lists. But to learn Haskell, I spent the first few years doing either list processing or very simple algebraic data types, and I think it made me a better programmer as a result.
If you want to program Haskell, get the basics sorted. Once you have sorted the basics of functional programming, you can move on to the Haskell specific bits. The course I learnt from at York left out things such as modules, type classes (beyond slight Eq/Ord signatures), monads, IO (other than interact) and anything not in Haskell 98. What it did cover very well was functional programming and functional reasoning.
Of course, after teaching these bits, say towards the end of a course or in a Real World Haskell book, the extra Haskell bits should definately be covered! They are what makes a Haskell programmer, but not what makes a functional programmer. Thanks Neil
Neil Mitchell wrote:
If you want to program Haskell, get the basics sorted. Once you have sorted the basics of functional programming, you can move on to the Haskell specific bits. The course I learnt from at York left out things such as modules, type classes (beyond slight Eq/Ord signatures), monads, IO (other than interact) and anything not in Haskell 98.
I think what you describe as "basics" is "basics of programmning" (i.e. how to write one "toy" function) and sure this is important. But I think the other topics (modules, classes, monads, extra libraries) are equally important because they are "basics of software engineering" (how to write/organize a bunch of functions that do some "real" work). I wouldn't call these "Haskell specific" because the underlying concepts are perfectly general - and if you leave them out, students will ask for them because they already know Java has a module system, and interfaces, etc. and they have been trained early to use this (this is basic undergraduate CS stuff, no?) Perhaps you're saying that *because* students already know that, one shouldn't spend too much time on it in a Haskell course. Agreed, but then my conclusion is to use e.g. (hierarchical) modules right from the start. I generally tell my students that Haskell has about everything you would expect from a modern general-purpose programming language (that's where I'd put modules, classes, libraries) *plus* additional benefits: more efficiency (in writing - you need less code because you have more ways of abstraction) and more safety (because of strong typing). This does not contradict what you write. Indeed one can practice abstraction and typing rules using functions over lists of lists of ints. Problem is that afterwards, the student knows about functions and types but still has to unlearn the habit of coding everything as lists of lists of ints... J.W.
participants (4)
-
Darrin Thompson -
Don Stewart -
Johannes Waldmann -
Neil Mitchell