TITLE: StrangeLoop 8: Reactions to Brett Victor's Visible Programming
AUTHOR: Eugene Wallingford
DATE: September 30, 2012 12:45 PM
The last talk I attended at StrangeLoop 2012 was Bret Victor's
Visible Programming. He has since posted an extended
version of his presentation, as a multimedia essay titled
You really should read his essay and play the video in which
he demonstrates the implementation of his ideas. It is quite
impressive, and worthy of the discussion his ideas have
engendered over the last few months.
In this entry, I give only a high-level summary of the idea,
react to only one of his claims, and discuss only one of his
design principles in ay detail. This entry grew much longer
than I originally intended. If you would like to skip most of
my reaction, jump to the mini-essay that is the heart of this
Programing By Reacting, in the REPL.
Programmers often discuss their productivity as at least a
partial result of the programming environments they use.
Victor thinks this is dangerously wrong. It implies, he says,
that the difficulty with programming is that we aren't doing
it fast enough.
But speed is not the problem. The problem is that our
programming environments don't help us to think. We do all of
our programming in our minds, then we dump our ideas into code
via the editor.
Our environments should do more. They should be our external
imagination. They should help us see how our programs work
as we are writing them.
This is an attractive guiding principle for designing tools to
help programmers. Victor elaborates this principle into a set
of five design principles for an environment:
Victor's talk then discussed each design principle in detail
and Processing.js in a web browser. The demo was cool
enough that the StrangeLoop crowd broke into applause at
leas twice during the talk. Read
As I watched the talk, I found myself reacting in a way I had
not expected. So many people have spoken so highly of this
work. The crowd was applauding! Why was I not as enamored?
I was impressed, for sure, and I was thinking about ways to
use these ideas to improve my teaching. But I wasn't falling
head over heels in love.
A Strong Claim
First, I was taken aback by a particular claim that Victor made
at the beginning of his talk as one of the justifications for
- 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
If a programmer cannot see what a program is doing, she can't
Unless he means this metaphorically, seeing "in the mind's eye",
then it is simply wrong. We do understand things we don't see
in physical form. We learn many things without seeing them in
physical form. During my doctoral study, I took several courses
in philosophy, and only rarely did we have recourse to images
of the ideas we were studying. We held ideas in our head,
expressed in words, and manipulated them there.
We did externalize ideas, both as a way to learn them and think
about them. But we tended to use stories, not pictures. By
speaking an idea, or writing it down, and sharing it with
others, we could work with them.
So, my discomfort with one of Victor's axioms accounted for
some of my unexpected reaction. Professional programmers can
and do manipulate ideas abstractly. Visualization can help,
but when is it necessary, or even most helpful?
Learning, Versus Doing
This leads to a second element of my concern. I think I had a
misconception about Victor's work. His talk and its title,
"Visible Programming", led me to think his ideas are aimed
primarily at working programmers, that we need to make programs
visible for all programmers.
The title of his essay, "Learnable Programming", puts his claims
into a different context. We need to make programs visible for
people who are learning to program. This seems a much
more reasonable position on its face. It also lets me see the
axiom that bothered me so much in a more sympathetic light: If
a novice programmer cannot see what a program is doing,
then she may not be able to understand it.
Seeing how a program works is a big part of learning to program.
A few years ago,
about "biction" and the power of drawing a picture of what code
does. I often find that if I require a student to draw a
picture of what his code is doing before he can ask me for
debugging help, he will answer his own question before getting
The first time a student experiences this can be a powerful
experience. Many students begin to think of programming in a
different way when they realize the power of thinking about
their programs using tools other than code. Visible programming
environments can play a role in helping students think about
their programs, outside their code and outside their heads.
I am left puzzling over two thoughts:
Mark Guzdial has written
a more detailed analysis of Victor's essay
from the perspective of a computer science educator. As always,
Mark's ideas are worth reading.
Programming By Reacting, in the REPL
My favorite parts of this talk were the sections on creating
by reacting and abstracting. Programmers, Victor says, don't
work like other creators. Painters don't stare at a blank
canvas, think hard, create a painting in their minds, and then
start painting the picture they know they want to create.
Sculptors don't stare at a block of stone, envision in their
mind's eye the statue they intend to make, and then reproduce
that vision in stone. They start creating, and react,
both to the work of art they are creating and to the materials
they are using.
Programmers, Victor says, should be able to do the same thing --
if only our programming environments helped us.
As a teacher, I think this is an area ripe for improvement in
how we help students learn to program. Students open up their
text editor or IDE, stare at that blank screen, and are
terrified. What do I do now? A lot of my work over the last
fifteen to twenty years has been in trying to find ways to help
students get started, to help them to overcome the fear of the
My approaches haven't been through visualization, but through
other ways to think about programs and how we grow them.
can give students tools for thinking about problems and growing
their code at a scale larger than characters or language keywords.
An agile approach can help them start small, add one feature at a
time, proceed in confidence with working tests, and refactor to
make their code better as they go along. Adding Victor-style
environment support for the code students write in CS1 and CS2
would surely help as well.
However, as I listened to Victor describe support for creating
by reacting, and then abstracting variables and functions out
of concrete examples, I realized something. Programmers don't
typically write code in an environment with data visualizations
of the sort Victor proposes, but we do program in the style that
such visualizations enable.
We do it in
A simple, interactive computer programming environment enables
programmers to create by reacting.
- How much of the value my students see in pictures comes from
not from seeing the program work but from drawing the picture
themselves -- the act of reflecting about the program? If
our tools visualizes the code for them, will we see the same
learning effect that we see in drawing their own pictures?
- Certainly Victor's visible programming tools can help learners.
How much will they help programmers once they become experts?
Designing the User Interface taught me that novices
and experts have different needs, and that it's often
difficult to know what works well for experts until we run
Programmers from the Lisp and Smalltalk communities, and from the
rest of the dynamic programming world, will recognize this style
of programming. It's what we do, a form of creating by reacting,
from concrete examples in the interaction pane to code in the
In the agile software development world, test-first development
encourages a similar style of programming, from concrete examples
in the test case to minimal code in the application class.
stimulates an even more consciously reactive style of programming,
in which the programmer reacts both to the evolving program and to
the programmer's evolving understanding of it.
The result is something similar to Victor's goal for programmers
as they create abstractions:
- They write short snippets of code that describe how a new
feature will work.
- They test the code immediately, seeing concrete results from
- They react to the results, shaping their code in response to
what the code and its output tell them.
- They then abstract working behaviors into functions that can
be used to implement another level of functionality.
The learner always gets the experience of interactively controlling
the lower-level details, understanding them, developing trust in
them, before handing off that control to an abstraction and moving
to a higher level of control.
It seems that Victor would like to perform even more support for
novices than these tools can provide, down to visualizing what the
program does as they type each line of code. IDEs with autocomplete
is perhaps the closest analog in our current arsenal. Perhaps we
can do more, not only for novices but also professionals.
I love the idea that our environments could do more for us, to be
our external imaginations.
Like many programmers, though, as I watched this talk, I occasionally
wondered, "Sure, this works great if you creating art in Processing.
What about when I'm writing a compiler? What should my editor do
Victor anticipated this question and pre-emptively answered it.
Rather than asking, How does this scale to what I do?,
we should turn the question inside out and ask, These are the
design requirements for a good environment. How do we change
programming to fit?
I doubt such a dogmatic turn will convince skeptics with serious
doubts about this approach.
I do think, though, that we can reformulate the original question
in a way that focuses on helping "real" programmers. What does a
non-graphical programmer need in an external imagination? What
kind of feedback -- frequent, even in-the-moment -- would be most
helpful to, say, a compiler writer? How could our REPLs provide
even more support for creating, reacting, and abstracting?
These questions are worth asking, whatever one thinks of Victor's
particular proposal. Programmers should be grateful for his
causing us to ask them.