I have mentioned here before that I was planning to teach CMPT 383. It ended up being a no-go this semester because of a very productive capstone project team (more on that later).
But, I’m on-deck to teach it in the summer. The class is full; the waiting list is full; must be time to plan a course. After much soul-searching, I have decided there will be three main topics in the course and they will be covered in this order:
- Functional programming (and Haskell)
-
This will be most students’ first introduction to a non-imperative programming paradigm (and associated language). Every little while I think this won’t take long, then I remember the list of things that have to be introduced to get anywhere with Haskell: being really good at recursion, list comprehensions, lazy evaluation, type inference, higher-order functions, and other stuff to be discovered as I try to teach the language.
From my perspective, there are two reasons to be talking about functional programming. First, it’s finding some relevance, probably because people want to parallelize things (e.g. CouchDB). Second, there are important lessons from functional programming that can be transferred to OO programming.
- “Language Features”
-
This section contains the big concepts of the course: type systems (static/dynamic, strong/weak, type coercion, duck-typing, late/early binding, …), interpreted vs compiled, pointers vs references, memory management, reflection, runtime environments, first-class functions, objects, exceptions, mutable/immutable objects, ….
The basic question here is: what are the real differences between the programming languages you have to choose from? How might they affect your choice of language for a project?
- Logic programming (and Prolog)
-
As much as I am aware that Prolog is pretty much confined to old school AI researchers, I still think there’s some value in being exposed to logic programming. It should be possible to translate back to the OO world the idea of expressing a problem as a series of constraints and then looking to satisfy those constraints.
To be fair, this is the chunk I am most unsure of. Part of the reason it comes last is that if anything should fall off the end of a full semester, it’s this.
The exact balance of the topics remains to be seen. I’ll guess 5 weeks, 5 weeks, 3 weeks.
As for getting marks, I am as far as:
- Lab exercises: weekly hour-or-two chances to practice the concrete skills.
- Assignments: like… two of them? One Haskell, one Prolog?
- Project: pick a somewhat obscure language from a list I provide. Explore it by writing a report and some programs with it.
- A midterm and a final exam.
No idea what I’ll ask on the exams. Maybe Warren has some old ones I can look at.
So there it is. Unless I change my mind.
April 20th, 2010 at 9:31 am
Would it be feasible to request the students, or teams of students, keep journals of their experiences? The learning curve for Haskell in particular is of great concern to those writing docs, so having some first-hand data of student experiences about where and how they became confused, and what resources they used to overcome that, would be advantageous.
Otherwise, looks slick.
April 20th, 2010 at 10:26 am
Please, no teams!
April 20th, 2010 at 10:27 am
By the way, Hugs ’98 has a nice example/demo/whatever of a Prolog inside Haskell. Could be useful for students wanting to see the inner workings of an interpreter, from the perspective of the language they just examined, for the language they are now inspecting. If you follow my meaning…
http://darcs.haskell.org/hugs98/demos/prolog/