The Art Of Teaching Computer Languages
by Joran Elias
27 February 2009
I need some help. I’m teaching a class called Introduction to Probability and Statistics. It is intended as a first course in prob/stats for math and CS majors, although there are always a smattering of students from other departments as well.
In addition to the usual stuff, the students are supposed to gain some basic proficiency at “basic tasks” in R. Usually, this means learning enough to answer “What’s the probability of…” questions using simulation (i.e. a for loop and some random number generation). I also use this as a tie-in to non-parametric estimation methods (i.e. bootstrapping in the stats half of the course).
The point is less the actual tasks they’re doing in R as exposing them to a major tool in statistics these days. So I’m essentially teaching a computer language.
Sadly, about half (out of 30 or so) the students have never been exposed to computer programming at all (!!!) and the other half have 2-5 languages under their belt (usually a subset of Java, C(++), Perl, Lisp and Python).
There are classroom management problems here, of course, with such a bifurcated class. But my real problem is just teaching the beginners how to get around in R. I just don’t have any experience teaching people stuff like this. It feels overwhelming for me (I don’t know where to start) and I’m sure feels overwhelming for the beginning students as well.
I’ve tried to boil it down to a simple list of concepts and commands like vectors, assignment, boolean comparison, for loops, and assorted useful commands (sample(), which(), any(), sum(), mean(), sort() and 2-3 others).
I feel like I’ve explained the following concepts, but the students’ behaviors are suggesting otherwise:
- The idea that expressions/functions return a result that need to be assigned somewhere for later use.
- The idea that variables (I try to avoid the word “object”, though maybe that’s a mistake) need to be created before they are referred to or used.
- The (syntax) idea that commands (i.e. functions) operate like mean(sort(x)) rather than like x sort() mean().
I’m not kidding about that last one. I’ve corrected that syntax error several times now, and it still crops up. Indeed, the very notion that R could possibly be serious about expecting code to be written in a certain way seems outlandish to a lot of students.
In one case, I tried to explain the syntax of for loops, which boiled down to saying that it just repeats the lines of code inside the {}, n times, incrementing the variable i by one each time. Several minutes later I helped a student who was simply incredulous that R was actually pissed that he hadn’t typed that final }. He had no problem with the for (i in 1:n) part, but was just flabbergasted that R could be so picky about a silly little curly brace.
Sigh.
Anyway, I’m feeling like a bit of a failure here. I’m sure it’s not entirely my fault, but still, I have zero experience teaching computer languages. Does anyone have any advice or experience that I might find useful?
Mar 1, 03:35 AM
Unfortunately, there is no silver bullet that is going to make this easy. I don’t know R, but I do have a little bit of experience of teaching various other programming languages to students at various levels of sophistication, so I can offer you a few observations that have helped me over the years. Your mileage may vary, and the usual disclaimers apply.
There is a sharp contrast between “learning to program” and “learning to program in language X”, no matter what X you may choose. Of course, when a student is learning to program for the first time, (s)he must choose some language, but the real challenge is acquiring the basic mental models necessary to understand what a program is doing. Some languages make this easier than others, but until the student has acquired some essential mental discipline for thinking about how to drive a computer, the syntax is the least of your worries.
Since your class isn’t about programming per se, you probably can’t afford to spend a lot of time on fundamentals, so your best bet may be to provide them with a bunch of working examples that do some of the common tasks they need. Start small—-even if it seems trivial—-and build up from tiny to small to large. How are variables created? How can they be used? How do input and output work? How do variables combine with functions? What operators does the language provide? Do you have to declare types? How do functions work? How can you write your own functions? How can you combine them to solve bigger problems? These sorts of questions are trivial to an experienced programmer, but are utterly opaque to the novice. A library of good examples can help them figure out which parts matter and which don’t.
At first, it will seem to them as if everything is essential—-as Rex Page from University of Oklahoma wrote to his students:
The other side of the coin is that even with good examples, the students won’t learn anything till they actually have to sit down and spend some quality time trying things and fucking up. Nobody ever learned to program without screwing up, and the more you screw up, the faster you learn. Seymour Papert observed that many students come to think of mistakes as terrible, anathematic things that should be hidden from view and forgotten as soon as possible. By the time they get to college, most kids have elevated this avoidance to a fine art. To counteract this, give them lots of exercises to do that require them to do stuff rather than get a particular result, and don’t grade it unless they don’t do it.
In the end, you can bring the horses to the river, but you can’t make them drink; some of your students may not, despite your best efforts, put in the time it takes to learn how to do it. The only thing I can advise you in those cases is not to lose heart.
Mar 4, 09:28 AM
I think debugging is one of the most frustrating parts of learning a programming language. You stare at the screen for 30 minutes then change a couple of characters that a more experienced programmer could have figured out in 10 seconds.
If you have the time, commitment and lab space, I’d give the students a list of simple tasks to work on while you wander around helping students. This allows them to see the pitfalls first-hand without spending 30 minutes getting frustrated. Since there probably won’t be enough of you to go around, you could also encourage them to ask their lab neighbors when they get syntax errors.
I haven’t taught programming… but that’s what I’d try.