Learnable programming

Khan Academy launched its new computer science environment last month. You edit some Processing.js code on the left, and a drawing on the right updates as you type. They credited Bret Victor’s Inventing on Principle talk as the inspiration. This week Victor published Learnable Programming, a very long essay that, politely but firmly, says they missed the point. Instant feedback is nice, but seeing the picture change doesn’t tell you why it changed.

The essay splits a programming system into two halves, the environment and the language, and spends most of its time on the environment. He wants it to help you read the vocabulary (hover over ellipse(50, 50, 30, 30) and it tells you what each number means), follow the flow (show the program running step by step, with time laid out so you can scrub through it), see the state, create by reacting, and create by abstracting. Each one gets its own set of mockups and they’re worth looking at, even if you skim the text.

The one that stuck with me is “see the state”. Think about how much of what we call being good at programming is really being good at running the program in your head. When I was 13 and writing Turbo C on DOS, my debugger was mostly printf and a lot of staring at the screen. You got good at simulating the machine because you didn’t have a choice, and I’ve always just assumed that’s what programming is, and a teacher’s job is to get people through that pain faster. Victor’s position is that the pain is a design bug. If the environment showed you the state you wouldn’t need to simulate it. I’m not fully convinced, but I haven’t been able to stop thinking about it either.

What I can actually change is how I teach. When I pair with a junior developer on an unfamiliar codebase, my instinct has always been to explain the structure: here’s the controller, here’s the service, this calls that. This week I tried it the other way around. We picked one real request, put a breakpoint at the front door and followed it all the way down, writing the values of the interesting variables into a text file next to the code, one line per step. A poor man’s version of his timeline. Before each re-run, he had to say out loud what he thought would happen. He was wrong a couple of times, and that was where the useful conversation happened. By the end of the afternoon he understood the code better than my structural tour would have managed in a week.

I don’t agree with all of the essay. A lot of his examples work because drawing programs are naturally visual, and I have no idea how you’d “see the state” of a distributed job queue the same way.* But I’d much rather be in an industry where someone’s working on that problem than one that thinks the debugger was finished in 1995.

* If anyone has seen a good attempt at that, please send it my way.