Computer magic

One of my colleagues often says that beginning CS students seem to think that computers work by magic. They sit in lectures and watch an experienced magician recite incantations, then go to the lab and type those incantations in for themselves. Understanding the incantations seems a bit optional. After all, this is magic -- who knows what could happen to the person that stares into the heart of it.

So, it is with some alarm that I'm observing my own use of the machines. My laptop is currently going bonkers and periodically refuses to boot. My incantation for solving this problem is to maniacally move the mouse during bootup. This might seem insane (and possibly is) but the hang-on-boot always happens when the message "Starting system message bus" appears and every time I've been moving the mouse in my paranoid way, the machine struggles a bit but finally manages to boot. When I forget the magical incantation I find myself looking round to see that I missed the error message and the laptop needs a hard reset. I can't decide whether these experiences consitute anything remotely falsifiable or not. Perhaps if I move the mouse without feeling paranoid I'd get a different result? What if someone else moved the mouse? Would they have the special spidey-powers to make it work? Who knows.

James points out that this particular incantation is due to a set of experiences that many people our age have suffered: using Windows 3.1. That damn thing really would just spuriously hang and moving the mouse at least gave you a clue as to when a reset was needed. The upshot is that a whole generation of us that wiggle the mouse whenever a web page takes a while to load.

Tempting, then, to base the course notes we're currently writing on a sub-natural understanding of how machines work. We could trade in our LaTeX times for something far more archaic and ask the Uni printers to use parchment for a change. Perhaps we could, at last, entice the Harry Potter generation to Uni and end the current down-turn in CS majors.

Chunking up and down

As I was eating museli this morning, it dawned on me that the failure of Objects First teaching is all to do with chunk size. Most students seem to think better in small chunk sizes during the learning process, then chunk up when they've gained competency. Objects require big-chunk thinking, because you need to be able to abstract over smaller chunks of information to think clearly about the structure of your programs. Beth Adelson did some fascinating work which showed that in programming, "experts" have much bigger chunk sizes than "learners". This bears out in the classroom too. The most common question I get asked by students who struggle with programming basically amounts to "what line of code do I write next". This tells me that they haven't chunked-up to thinking about algorithmic structure, so I know they won't cope well with object structures.

Objects-First expects students who cannot chunk large to do so, and it's no wonder they get so confused! My intuition on this is that OO-First will soon fade out pretty soon as a pedagogical fashion and Python will help enormously. In Python you can choose no program structure, functions, objects, whatever you want, so teachers aren't constrained to an OO-First approach. Unlike Java, an un-structured program needn't jump through hoops to print a word to the screen, so students have the benefit of being able to learn one chunk at a time.

Functional programming in Python

I was dismayed to read about Guido wanting to remove lambda, reduce, map and filter from Python. Although Guido's point about list comprehensions (and indeed the shocking complexity of some "fold" style transformations) is sensible, I'm not convinced that reducing the nice mixture of functional / imperative / OO is the best way to go. I mean, people can write spaghetti code in any paradigm, that doesn't mean we should abolish nested loops or multiple inheritance, right?

It was disappointing to read that Guido things that arithmetic is where functional style stuff is used most (well, I'm paraphrasing a bit there). While this might be true for reduce (or not, I dunno), it certainly isn't true for the rest. String munging and simple parsing is a good example of where the functional style can be very elegant. For example, the following takes a type declaration of the form "int, int, int -> int" and returns a list of the constituent types (e.g. ['int', 'int', 'int', 'int']). Of course, you could do this with loops, or regexps, or a lexer generator (!), or whatever, but the functional style is just so damn nice to look at:

def parse_types(s):
  import string
  def rem_arrow(s):
    return filter((lambda x: not(x == "->")), s)
  def strip_commas(s):
    return map((lambda x: rstrip(x, ',')), s)
  return rem_arrow(strip_commas(string.split(s)))

Note, that I could have used a bunch more lambdas here, but explicit def's are more readable. Whilst Guido complains about over-use of lambda, this is a matter of good style.

Bob tells me that someone once said (Abramsky?) that good language design should make anything semantically undesirable syntactically impossible. Here, Guido is trying to make bad stylistic decisions syntactically impossible, which I guess is the opposite view to Perls many ways to do everything and all of them unreadable. I have some sympathy with Guido's view, but can't help feeling pretty heartbroken about the idea of losing lambda.

Oh, and I'm not (nor have ever been) a Lisp or Scheme hacker.

Python for introductory programming

It's been a seriously deficient amount of time since I last blogged; although James has been keeping up better and has even posted his excellent noise.

Like James I've been thinking a lot about the new Creative Computing course, which is one of the most exciting teaching-related things going on at the moment. Python will, of course, rule as an introductory language, and one of the nice things about it is how easy it makes "difficult" tasks. At the moment I've really fallen for the turtle module, which implements Papert-style turtle graphics -- something I've been meaning to hack onto Java for ages, and never got around to. In particular, turtle.py provides both an imperative and OO interfaces, making it ideal for leading students through different stages of the curriculum. Of course, it's also great for all sorts of things like recursion (think von Koch curve).

Looking through the available text books, there's some great Libre material, including the excellent Dive Into Python (for experienced programmers). One dissappointing aspect of many books I've seen is a lack of examples. Many texts seem to introduce one major concept per chapter, each with one long worked example. To my feable mind that's just not enough and (to quote someone clever) there should be more than one way to do everything, and that should be made clear to students. After all, flexibility of thought is, I reckon, one of the major attributes of a good programmer and it can only be taught by endless exposure to different styles and techniques. Python is also nice for this; it has great facilities for pure functional programming along with fantasticly nice syntactic suger for all the major imperative structures. What could be better for beginners?

Rotting your brain...

I'd forgotten all about this, but John reminded me that email rots your brain, dropping as many as 10 IQ points. Ouch!