Brett Victor has published a number of essays and lectures on new visual ways of programming which I've encountered through Twitter:
This article is a response to some of the backlash I've seen to the last one, Learnable Programming, some of which is informed by his earlier works.
I haven't looked for much backlash, so maybe it's not as widespread as I imagine. Rather, I just know I had my own reaction to his essays, and then through social media I came across two reactions to it which echoed my reaction and which I'm now imagining to be representative.
The two reactions are, roughly, of the form:
The former is typified, perhaps, by Programming For Morons. Although it is hard for me to pull a coherent argument that actually makes sense (most of his his claims are that Victor's essay is just 100% bullshit--often rejecting out of hand perfectly reasonable comments--or him misunderstanding Victor's terminology), I think it argues, in part, that it is important for programmers to internalize the sorts of things Victor is talking about ubiquitously visualizing instead of internalizing.
Unfortunately, that is an Arrogant response, one that comes across as reactionary. This is the way it works for him, so this is the way it should work. As he says of Victor, I'm sure he means well by this; he's not trying to promulgate an old boy's club where only the people who are already capable are allowed admittance. But that's what it amounts to. The old ways are the best ways.
But it's clearly wrong. It was easy for me to learn to program too; I took to it naturally. But clearly most people don't! In fact, we need look no further than the gender imbalance in programmers to know that something is rotten in the state of programming education.
A Humble response would be "this isn't how programming works for me, so I don't understand why it would make sense for other people like me."
The Other response would be, "this isn't how programming currently works for me, but it might be good for others and maybe it could even improve my experience."
The second reaction, that visualization only works in some domains, has an example here. While less aggressively condemnatory, it still argues that Victor is missing the big picture. Visualization is all well-and-good for easily-visualizable problems, but it makes no sense for the vast majority of things most programmers do.
The Arrogant response here is "this will never work in my problem domain". The Humble response is "I don't see how this would work in my problem domain." The Other response is "Let's see if we can figure out how to make it work in my problem domain".
I think some of the reaction comes from the unexpected turn "Learnable Programming" takes: it starts off talking about how to set up an educable programming environment, and it ends up saying that all programming should be this way, and all programmers should be this way.
You can imagine how that might set off a reactionary response.
I don't know why Victor used this rhetorical device. IMO it undermines his primary goal (responding to the Khan Academy live-programming environment), and it makes it a lot harder to talk about his essay, since he really has two superposed arguments.
So let me get this out front: as long as we're talking about programming education, I'm in 100% agreement with Victor. What he proposes is a million times better than the Khan Academy live-programming environment, in terms of giving people an environment in which they could play and discover and learn programming on their own. Yes, people like me and the codingwisdom guy didn't need that leg up, but I imagine there are others whom it would help.
And despite what some people might think, it's not going to hurt them. We're not going to breed a class of programmers overreliant on these helper things and unable to think for themselves. The point of turtle graphics in Logo isn't to give people an easy device so they can see why their program produces the graphics it does (by watching the turtle draw it slowly), it's to give people an easy mechanism that they can eventually internalize and understand why their program produces the graphics it does without the aid of the slow visualization. They can always turn on the slow visualization if they hit a rough spot, but the whole point is to build them up until they imagine the work of the turtle. Given the success of Logo in academic circles, my operating assumption is that it succeeds at this goal.
If starting on BASIC didn't ruin me and my programming peers from the early 80s, neither would starting on Victor's system.
The above describes my take on this essay when it comes to programming education. But what about for programming in general, which Victor's essay also attempts to address?
When I first read Learnable Programming, I had both Arrogant responses to the essay. But I recognized the value for the educational scenario, so I shut my mouth and retweeted it.
I've learned to be arrogant about my skill as a programmer. For most of my life I always was (or seemed to be) the best programmer in the room. And while I try to be humble and self-effacing about most things, it seemed more valuable to recognize the skill as the skill it was and to not downplay it. And it seems like there are a lot of other programmers out there like that. And I think that makes the arrogant response really easy.
But as I thought about the essay further, I switched to the Humble responses. I don't know what's right for other people, and I don't know everything.
But reading those other replies to Victor, I've switched to the Other response. Maybe there is something here.
Debugging is one of the worst parts of programming. I'm great at debugging, but debuggers are terrible. I've always wanted better debuggers, better visualizations, better ways to understand what code does. (The secret sauce of my company's new video codec for videogames probably isn't the really codec itself, but the sophisticated visualization/analysis system that was written to help develop it, because of exactly this problem.)
Visualization may be hard, but it's probably not impossible. Simple example: the problem in "The Ladder of Abstraction" isn't technically a visual problem, although it is easy to visualize. But eventually he climbs the ladder of abstraction to produce a 2D graph that has nothing to do with the spatiality of the problem itself.
What about totally non-visual problem domains? In "Inventing on Principle" he explores a binary search, a problem known to be tricky to get right at least since Bentley's Programming Pearls called attention to the difficulty. In "Learnable Programming" he talks about having new, different data structures engineered around being "learnable".
It's not clear where these magic IDEs would come from. Clearly Victor's is purpose-built to his specific problems, and he's not offering concrete proposals for how to make this stuff happen. I think you have to read him as signposting: he's pointing a way that this stuff could go, and encouraging us to go there with him.
Yes, visualization would be a bunch of work. But so is test-driven development. If we can get a whole philosophy of software engineering where people write more tests than they write "actual" code, where they write the tests before they write the actual code, then maybe an approach where people write visualizations with the same rigor and effort that they write tests would make sense!
If you go look at Victor's binary search from "Inventing on Principle", you'll see a problem with his visualization of it: he's binary searching over a tiny data set. He's only doing an easy case; his visualization approach would never work for a larger case.
That's the arrogant response.
The humble response is: I don't see how it could work for a larger case.
The other response: Let's see if we can figure out how to make it work for a larger case.
Sean Barrett
2012-09-28