Thoughts on Thoughts on Bret Victor’s “Learnable Programming”

Bret Victor published a long essay entitled “Learnable Programming” in September 2012 in which he described principles for creating both better programming languages and better programming environments for beginners and experts alike. But unfortunately, not everyone agrees with his stance.

Many expert programmers still exhibit forms of machoism when it comes to programming, which I find does more harm than good. Instead of acting like a voice of skepticism, it comes off as a voice of elitism with a disregard for the difficulty of beginners to develop computer program writing skills, the difficulty of programming as an expert, and the importance of a computer-literate population.

Mark Chu-Carroll objects to Bret’s stance, and the idea of programmer’s making it hard for beginners to program on purpose:

For some reason, so many people have this bizzare idea that programming is this really easy thing that programmers just make difficult out of spite or elitism or clueless or something, I’m not sure what. And as long as I’ve been in the field, there’s been a constant drumbeat from people to say that it’s all easy, that programmers just want to make it difficult by forcing you to think like a machine. That what we really need to do is just humanize programming, and it will all be easy and everyone will do it and the world will turn into a perfect computing utopia.

I don’t think Bret is arguing that at all. He’s not saying programmers have intentionally made it difficult for outsiders to join our circles, but that, well, it just is hard for outsiders to join. That instead of explicitly not doing our best, we have been doing our best but that our best isn’t good enough, and the sooner we can admit that and start improving, the better. This is not a bad thing. Improvement is what programmers do all day long, so why not also improve programming itself?

Mark continues:

To be a programmer, you don’t need to think like a machine. But you need to understand how machines work. To program successfully, you do need to understand how machines work - because what you’re really doing is building a machine!

Again, I don’t think Bret is advocating not understanding how a machine works. In fact, I think he’s advocating quite the opposite — by creating a better programming environment and language, it can better enable a new generation of programmers to visualize and understand their programs than ever before. I’ll return to this point in a moment.

John Palvus, writing for the MIT Technology Review backs this up:

Victor thinks that programming itself is broken. It’s often said that in order to code well, you have to be able to “think like a computer.” To Victor, this is absurdly backwards—and it’s the real reason why programming is seen as fundamentally “hard.” Computers are human tools: why can’t we control them on our terms, using techniques that come naturally to all of us?

The main problem with programming boils down to the fact that “the programmer has to imagine the execution of the program and never sees the data,” Victor told me.

Or as Bret wrote in his essay:

Maybe we don’t need a silver bullet. We just need to take off our blindfolds to see where we’re firing.

Neil Brown retorts to this statement that while showing visualizations to newcomers is useful, it’s a nuisance to experts:

One of the first things beginners do in any area is learn the terms, after which I believe the labelling of program constructs becomes annoying rather than helpful. We wouldn’t have a mouse-over helper in Maths saying ” ‘+’ is the symbol meaning add two numbers” or in French saying “Je means I” — you learn it early on, quite easily, and then you’re fine. The point of the notation is to express concisely and unambigiously what the program does. I can understand that the labels are a bit more approachable, but I worry that for most cases, they are not actually helpful, and very quickly end up unwieldy.

But again I feel like this is missing the point. I think the example of labels in the programming environment are really just a stepping stone — one stop on the road to being able to see and understand what a program is doing — but it’s not the only thing. Labeling the environment is one thing, but the concept can extend further to enable the experts to reach a higher ground. Sure, experts already know the syntax and probably most of the library functions too. Great, now that can be trivialized, and even better, new and more specific program parts can be visualized. Now things which are specific to the application can be labeled and explained, in context, for all developers of a given project.

Neil continues on other topics of visualization:

I propose that visualisation doesn’t scale to large programs. It’s quite easy to visualise an array of 10 elements, or show the complete object graph in a program with 5 objects. But how do you visualise an array of 100,000 elements, or the complete object graph in a program with 50,000 objects? You can think about collapsible/folding displays or clever visual compression, but at some point it’s simply not feasible to visualise your entire program: program code can scale up 1000-fold with the tweak of a loop counter, but visualisations are inherently limited in scale. At some point they are all going to become too much.

I think this is a very narrow-minded way to approach Bret’s essay. As someone who writes code blindly like we currently have to do, of course we’re going to have a hard time coming up with ways to visualize our data, but fortunately for us there’s a whole field to solve this very problem: Data Visualization (for anyone who’s interested in learning more on this topic, you absolutely should read the works of Edward Tufte). As programmers, we’re bad at visualizing data because we’ve never thought of it as a necessary skill. But once our eyes are open to the benefits of data visualization, then not only does it not seem impossible, it also starts to seem necessary.

Neil thinks we don’t have to see to understand:

Someone once proposed to me that being able to create a visualisation of an algorithm is a sign of understanding, but that understanding cannot be gained from seeing the visualisation. Visualisation as a manifestation of understanding, rather than understanding as a consequence of visualisation. I wonder if there’s something in that?

I disagree, and believe there’s much to be gained from understanding the relationship of seeing and understanding a concept. Alan Kay, building on the work of Piaget and Bruner had the insight which he summarized as follows:

Doing with Images makes Symbols.

This is a relationship between three human mentalities, where we work with body, the visual system, and the symbolic mind in different but complimentary ways. These act as a continuum of thought and interaction and movement within that continuum is essential. So to have real understanding of something on the symbolic level, it’s so much more natural to achieve this if you not only have images to work with, but also actually interact with those images as well. This is one of the essential, founding principles of the modern graphical user interface, a fact which is lost on almost all of its users.

Neil concludes his argument:

I like the blindfold metaphor, because it fits with our understanding of expertise: “he can do that with his eyes closed” is already a common idiom for expertise in a task. Beginner typists look at the keys. Expert typists can type blindfolded. Therefore at some point in the transition from beginner to expert typist you must stop looking at the keys. So it is with programming: you must reach a stage where you can accept the blindfold.

Which unfortunately also brings to mind The blind leading the blind metaphor. Lots of experts claim to be able to do something “with one hand tied behind my back”, but none would elect or suggest always working under such conditions. Nobody should be proudly held back at doing the best they possibly can at their work! Accepting the blindfold conditions for both beginners and experts alike is accepting the current state of programming as the best it can be, without any hope for improving the situations for generations to come.

At the end of the essay, Bret says what I believe is the real crux of his argument:

These design principles were presented in the context of systems for learning, but they apply universally. An experienced programmer may not need to know what an “if” statement means, but she does need to understand the runtime behavior of her program, and she needs to understand it while she’s programming.

Our society has deemed book literacy an essential skill as it’s a key mechanism in which our society thinks. Computers can offer an even better medium for society to think in, but only if we strive for computer literacy as well. And as with written literacy, this means both reading and writing. Expecting an entire society to write programs the way “experts” write them today is ludicrous, inscrutable, and counterproductive. If we’re to expect members of society to be computer literate, then we must create for them an environment where thinking can be expressed even better than on paper*.

*Yes, this is one reason why Cortex has yet to be released. I’ve yet to solve the problem of understanding and visualizing a Cortex plugin, and without that, it’s cripplingly difficult to create useful programs. This needs to be solved, because it’s irresponsible to expect developers to imagine it all in their heads.