Everybody seems to be blogging about the multi-media essay Learnable Programming by Bret Victor.
I read it and found some of it interesting, but it seemed rather narrow-minded and dogmatic to me. Already in the 3rd paragraph, there was a statement ringing alarm bells for me:
People understand what they can see. If a programmer cannot see what a program is doing, she can’t understand it.
If that were really true, then blind people would be incapable of programming, but this is demonstrably false. Blind programmers may be rare, but they have certainly been around for the last 30–40 years.
If Bret had said “If a programmer cannot imagine what a program is doing, she can’t understand it,” then I would have nodded my head and agreed with him. But he specifically wants to argue that all programming instruction and perhaps all programming should be visual, a conclusion that I do not support. I’m not even certain that the visual representations of data that he regards as essential are even helpful.
Other than his insistence on visual modes of thinking and interacting as the only valid modes, he has some pretty good ideas, which he outlines as a set of design principles:
The environment should allow the learner to:
- read the vocabulary— what do these words mean?
- follow the flow— what happens when?
- see the state— what is the computer thinking?
- create by reacting— start somewhere, then sculpt
- create by abstracting— start concrete, then generalize
The language should provide:
- identity and metaphor — how can I relate the computer’s world to my own?
- decomposition — how do I break down my thoughts into mind-sized pieces?
- recomposition — how do I glue pieces together?
- readability — what do these words mean?
One aspect of the “essay” that I found irritating was the frequent embedding of things that looked like video play buttons, but which did not seem to do anything except disappear when clicked on. I examined them with Firefox’s “Inspect Element” tool, and found that they were Chrome-specific extensions to make videos. I viewed a couple of them using the Chrome browser, and found that they just slowed the essay down without adding much to the content. Still, it seems strange to me that someone who wants to be read would deliberately hide parts of his content in non-standard formats. Perhaps Bret is more enamored of flashy features than he claims to be, or perhaps he thinks that the flamboyant visual style of his essay is essential to understanding it—I found the extreme typography more an irritant than an aid.
I doubt that Bret would get far as a bioinformatician, since he strongly holds the view that “only visually understandable data is considered sound”, but most of our data is too voluminous to handle with purely visual understanding. We have to trust abstractions that we can’t see, because there is no way that we can visualize the terabytes or petabytes of data that make up our databases.
Of course, Bret is right that visualizing data is a very powerful metaphor, much more powerful than visualizing programs. Huge amounts of effort go into coming up with new ways to visualize genomes, interaction graphs, protein structures, signalling pathways, metabolic networks, alignments, and other computational artifacts of bioinformatics. The visualizations are often extremely valuable in viewing small parts of the data.
Better visualizations do allow better views of the data: for example, sequence logos allow a summary view of an alignment with tens of thousands of sequences in it, showing what is conserved through evolution clearly. But viewing all the individual sequences (as earlier visualization tools did) is totally useless.
But visualization of data is just a metaphor, and, like all metaphors, it breaks down sometimes. Some of the things we deal with frequently (like neural network weight matrices and parameters of SVM machines) are not particularly amenable to visual interpretation, and I would argue that they don’t need to be. We can understand them well enough without seeing them, and seeing them wouldn’t add to our understanding.
Bret’s essay is an interesting one and worth the time to read, but far from convincing to me. I don’t want students to “debug a program into existence”, which is essentially what his “create by reacting” and “create by abstracting” processes are. I want students to think before they act, at least much of the time, whereas Bret wants them to think after they act.
Some of the user interface issues he describes are interesting design challenges (like a graphics library designed for auto-completion), but I doubt that the design challenges could be met by a programmer who programmed in pure versions of the “create by reacting” and “create by abstracting” modes that Bret describes.