Syntax errors made easy

Tuesday, 24 July 2007 — 8:57pm | Computing

As some of you know, I’m spending a nontrivial chunk of the summer teaching kids (lower bound: 11, upper bound: 15) to make their own computer games. They are given five days and a copy of the Torque Game Engine that I modified and compiled for the specific purpose of their prescribed activities. There is, unavoidably, a bit of coding involved.

Something that has always piqued my curiosity is the pedagogical difficulties involved in the instruction of computer programming. I speculate that ill-designed or ill-instructed introductory courses at the freshman level are, in all likelihood, directly responsible for the loss of a significant number of potential students in fields related to computing. When it comes to the matter of instruction, the problem often lies in the gap that exists between instructors that have completely internalized an intuitive sense of what is correct, and students that have not even begun to develop that foundation.

If you look at student essays, even those that are written at the university level, there’s a similar gulf between those who effortlessly arrange words into sentences and sentences into arguments – the former is a grammatical activity; the latter, logical and rhetorical – and those who still struggle with comma splices and coordinate conjunctions, never mind the trouble they subsequently encounter in the minefield of logical fallacies. When something resides in the realm of intuition, one neglects to decompose it into its component subproblems. It’s especially true of fluency in a given language, natural, programming or otherwise.

To absolutely nobody’s surprise, I invariably favour an educational approach built on a strong foundation of fundamental principles. You can’t make a musician out of someone who emulates notes on a page without any thought to chords and scales and how they apply to the inferential shaping of a sensible phrase, and you can’t make a (procedural) programmer out of someone who doesn’t have a basic and language-independent understanding of control flow.

For example, it is my belief that if you have any aspirations to work with computer programming in any capacity, you should have some exposure to recursion as early as possible. True to the title of Donald Knuth’s monograph on the subject, programming is an art. There exist brownie points for elegance. If I had it my way, I’d wean everyone on Lisp.

However, when you only have a week, and the students are impatient to get underway with a tangible project that does something, you have to take some shortcuts; providing them with a game engine and a lot of code already filled in is only the first step.

Here are some points of confusion an even mildly experienced programmer familiar with the lingua franca of C/C++ (the syntactic elements of which are as generally applicable as periods, commas and the Roman alphabet are to most European languages) might completely overlook:

When do we use curly braces, as opposed to square brackets and parentheses? (This is a particular challenge of denotative ambiguity when it comes to youths, who by and large still refer to parentheses as “brackets.”)

When does case sensitivity matter?

Does such-and-such still work if we don’t type in the tabs and spaces?

Is that the letter O or the number 0?

A veteran programmer tends to consciously think about those issues about as much as a pianist scrutinizes his chromatic scale fingerings note by note. He doesn’t think about it at all; he just does whatever makes sense.

Previous:
Next:

submit to reddit

Say something interesting: