Teaching programming

14 October 2011

One thing we wanted to do with PythonAnywhere, our Python online IDE and web hosting environment, was put together a short introduction to Python for non-programmers. I wrote the first cut the other day.

I’ve always been a fan of the Pimsleur language lessons. Unlike very traditional ways of teaching foreign languages, they don’t make you learn vocabulary lists and grammatical rules. Unlike more modern systems, they don’t try to teach you phrases. There’s no written textbook, just a bunch of CDs (or these days MP3s). And they throw you right in at the deep end.

At the start of each Pimsleur course, a soothing voice says something like “Welcome to Pimsleur Klingon part one, lesson one. Listen to the following conversation.” And then you hear something that sounds like this. The soothing voice comes back and says “in 30 minutes you’ll hear that again, and you’ll understand it.” And then you’re introduced to the different sentences, and told to repeat stuff. “Repeat this: tlhab ‘oS ‘Iw HoHwI’ So’ batlh” they’ll say, and you’ll stumble your way through it. Then they’ll get you to repeat “tlhab” on its own a few times. For complicated words they’ll break it down, and get you to repeat the last bit first, gradually building up. “I”. “wI”. “oHwI”. “HoHwI”. After 30 minutes of this, your brain is aching, and then they play the conversation you heard at the start — and it makes perfect sense!

Quite incredible.

So what’s this all got to do with teaching programming? Well, we were looking for a decent “Python for non-programmers” course that we could use, and while we found a couple, they all seemed to have the same problem — they’d work by gradually introducing simple concepts, and after twenty pages you might have learned enough to write a trivial program.

That’s not how any of us learned programming. Instead, we tended to pick it up bit by bit by inspection of complete working bits of code. For me, it was typing in listings from the home computing magazines that I bought. (Note for younger readers: listings were printed programs in magazines in the days when disks were too expensive to give away with magazines. (Note for even younger readers: disks were primitive USB-stick-like things that people used to use to store data, and were often attached to magazines as a way of passing data from magazine to reader in the days when you couldn’t just put a URL in the article text. (Note for yet younger readers: magazines were collections of very thin slices of wood on which text and images were “printed” using chemical dyes, which could be purchased in places called shops. They were popular in the Dark Ages before the Facebook.)))

That way of learning — which must be even easier now that any aspiring programmer can look at the source of tons of open source software, or just view the source of any web page — was quick, efficient, and got you straight to a position where you felt you’d achieved something. You’d written your first program! You could change the bits you understood, and leave the rest for a later day when you knew more. A great way to learn, as well as being excellent training for later days when you find yourself maintaining some horrific codebase written by someone who thinks that operator overloading is the best thing since sliced bread.

So, my theory for the first part of this tutorial — and, if it works out, for any following ones — is that each should start with a program listing that the reader won’t understand yet, but should be able to understand with a little explication. Core concepts should be drilled in by relentless repetition. No baby-talk — start using the technical terms straight away, and then repeat them enough that if the reader forgets what “variable” means then they can work it out from context. And aim to get them from knowing nothing to simple OO and functional programming in five half-hour lessons.

What do you think?

7 thoughts on “Teaching programming

  1. Andi Smith

    Hmm, I think part of the problem is that there is a real difference between reading text and listening to spoken word.

    In my experience, when a reader reads something that they don’t understand they tend to drift off – either dismissing the tutorial as “too hard” and giving up; or trying to re-read what was written before so they can try to find what they have missed.

    Even though you are telling them afterwards that you will explain it, some people won’t even reach that point and others will decide that your tutorial is not beginner enough for them.

    With the spoken word, I find that if someone doesn’t understand something, they are more forgiving and will listen for an explanation (it’s rude to stop listening to someone mid-way through a speech).

    That being said this is a nice idea to try, and I’d be interested if you find it works for you.

  2. jasiek

    How about writing a simple program that produces an incorrect answer for a well defined problem, and asking the user to fix it?

  3. njr

    Interesting idea. Gotta be worth a try.

    I never did the typing out listings thing. I mostly read the Z-80 instruction set booklet and when I got to the end figured I knew everything there was to know about progamming the Z-80. But there are probably better ways…

  4. Daniel Black

    I remember learning BASIC by typing programs from BYTE magazine on my TRS-80. These days (almost 30 years later), I’m making a serious attempt to pick up Python. I initially thought I’d read through a Python text (Core Python Programming) and do exercises. I feel that reading the text sequentially has definitely helped; even if I don’t recall everything, I have a sense of it and know where to find what I’m precisely after. Sometimes knowing a thing exists (e.g., a particular string method) is enough.

    But I haven’t completed more than a handful of exercises. Rather, I’m hacking up a modest application I’m interested in, and digging out the tools I need as I need them. I think of it as learning by using tracer bullets (http://pragprog.com/the-pragmatic-programmer/extracts/toc : Chapter 2). This sounds like your proposed methodology, and like in the BYTE programs or your listings. I think it would work nicely for folks who learn well this way (a tautology, I know).

    Not sure about a good length or schedule, but 2.5 hours *sounds* aggressive.

  5. Steve Holden

    This sounds very like the “useractive” philosophy behind the O’reilly School of Technology classes (I have just finished a three-year project generating a series of four Python classes). They have you enter code *by typing*, not copy-and-paste, and you then run and edit it.

    I have already brought Python Anywhere to their attention. I really think it’s going to hugely increase Python’s availability and popularity, and am already wondering what new training possibilities it opens up.

  6. giles Post author

    @Andi — you may be right, there’s also the point that when someone’s doing a Pimsleur course they’ve already invested real money in learning so they’re less likely to give up than someone who’s just chanced on a web page. Still, I do hope that the readability of simple Python programs like the one in the tutorial will help balance that out a bit. As you say, time will tell.

    @jasiek — that’s a great idea, perhaps a slightly later part of the tutorial but it could definitely help. $LARGE_PERCENTAGE of programming is debugging, after all. That’s why I like telling people to type in the code rather than the trypython.com trick of having a button to copy/paste — it’s amazing how much one learns from typos when starting a new language.

    @njr — you obviously started at a higher level than I did ;-)

    @Daniel — I had a very similar experience, mostly through mags called things like “Amstrad CPC Computing” rather than Byte. But yes, once you’re at the stage where you can start hacking on real live code, then just doing that rather than reading books is the way to go. IMO once you’ve spent some time doing the practice then it’s time to go back to theory again, but there’s little point in learning about clever recursive techniques before you’ve written something useful for yourself and got the coding habit.

    @Steve — I should have guessed there’d already be a name for it, and that O’Reilly would be keen on in (and that you’d be involved)… Totally agreed re: typing — not only is the typo-driven learning I mentioned in my answer to jasiek, there’s also the way it just beds in better when you actually code it yourself. I guess Pimsleur’s insistence that you repeat the word fragments, words and sentences in the language you’re learning hooks into the same thing. Thanks for passing on the word about PAW, we’ve got great hopes for it as a learning tool.

Comments are closed.