Computers as Objects to Think With
Bret Victor wrote an essay in 2012 that left me desperately wishing I were a computer engineer. “Learnable Programming” was a critique of 1) Khan Academy’s newly released intro course on programming, 2) the Processing language the course focused on, and 3) decades of stagnation in programming pedagogy. The essay was funny, visually stunning, provocative, and so convincing in its presentation of an effective foundation for how to teach programming to learners by showing them what their code was actually doing that one could easily be led to believe that anyone who’d even considered the question of how to teach programming before was asleep at the pedagogical wheel. The intellectual effect was something akin to a first encounter with Edward Tufte’s suggestion that graphs should show information instead of junky non-information. It was brilliant in a way that makes your temples burn and your mouth keep murmuring, “Yes. Yes. Yes!” Computers are awesome. Education is awesome. Teaching students how to do powerful things with computers = Best. Thing. Ever.
Ergo, I desperately wished that I knew enough about programming to join whatever project Victor was about to suggest.
Pivotal to the essay was the (brief) intellectual history of older languages and computer environments explicitly designed to teach students about programming. In this, Victor was unequivocal on the importance of Mindstorms:
The canonical work on designing programming systems for learning, and perhaps the greatest book ever written on learning in general, is Seymour Papert’s ‘Mindstorms.’
Given the brainy rush induced by Victor’s essay, I had no other choice than to follow his direct instructions, “For fuck’s sake, read ‘Mindstorms.’” So I ordered a used copy within minutes of reaching the bottom of his article.
Mindstorms was published in 1980, while Papert worked at MIT, so he uses terms like “cybernetics” in earnest and offers astounding facts like “in the past two years, over 200,000 personal computers have entered the lives of Americans” (p 181). So in that sense, the jargon and computational enthusiasm resonates with Tracy Kidder’s The Soul of a New Machine.(I.e. it’s very dated, but remember that you’re reading this for history and theory.) Now set this in concert with Papert’s vision for the role of computers in building learning environments for children: it is grounded firmly in his years of work with developmental psychologist Jean Piaget, a pioneer of constructivist education theory. The “build it yourself” and “ask lots of questions” spirit resonates with my 80s memories of LEGO sets and Sesame Street. Taken together, Papert’s ideas, read three decades later, crystalize for me a certain utopian fetish for the intellectual, cultural, and political possibilities of kids screwing around with boxy, green-screened Apple IIes.
But on a more practical level, the book is full of clear-eyed distillations of how tinkering with computers can help teachers and students make thinking visible. Take, for instance, Papert’s ideas here about the pedagogical power of “debugging” a computer program as a special case of tenacious learning-by-experiment:
The question to ask about the program is not whether it is right or wrong, but if it is fixable. If this way of looking at intellectual products were generalized to how the larger culture thinks about knowledge and its acquisition, we all might be less intimidated by our fears of “being wrong.” This potential influence of the computer on changing our notion of a black and white version of our successes and failures is an example of using the computer as an “object-to-think-with.” It is obviously not necessary to work with computers in order to acquire good strategies for learning. Surely “debugging” strategies were developed by successful learners long before computers existed. But thinking about learning by analogy with developing a program is a powerful and accessible way to get started on becoming more articulate about one’s debugging strategies and more deliberate about improving them (p 23).
Thirty years on, there’s a profusion of non-profits, projects, and start-ups trying to teach kids and adults alike to code. But what often goes unstated in the breathlessness about how cool it is to learn how to code is that fact that learning to code is, like learning to read and write, an extension of learning how to think. And learning how to think requires learning how to be “metacognitive”–that is, able to think about how your own ideas and thought processes work, so that you can find problems and correct them.
The LOGO interface allows users to draw using simple commands. Here’s one way to draw a square:
FORWARD 100 RIGHT 90 FORWARD 100 RIGHT 90 FORWARD 100 RIGHT 90 FORWARD 100 RIGHT 90
This code it easy enough to decipher: go forward 100 units, turn right 90 degrees, repeat 4 times, and you’ve drawn 4 straight sides at right angles to one another.
But I believe that part of Victor’s fascination with LOGO as a teaching tool lies in the simple metaphor of the Turtle. The Turtle is the stylus implied in the lines of code above. In LOGO, the “cursor” that moves around the screen, drawing your square (or whatever other shape) is called the “Turtle,” and all the written commands in the code are simply instructions to the Turtle for where to go and what to do. The Turtle is a little metaphor that helps to crystalize the fact that writing an effective program is nothing more than figuring out how to provide a cute, determined animal with the right set of instructions.
(Screengrab from the LOGO Foundation site)
But here’s were things get cooler. Papert’s team didn’t just build LOGO software and use it to help students experiment with mathematical principals while drawing shapes on green computer screens. The were also real Turtles students could control using the exact same instructions. These real Turtles were dome-shaped motorized robots with retractable styluses in them that would draw programed shapes and images on swaths of paper laid out on the classroom floor.
The link between the simple mathematics of a computer program and the real images a student could create is a perfect example of constructivist learning. Tinker with something abstract, see the results in the real world. Repeat over and over and the learner’s understanding improves.
Furthermore, the conceptual link between the instructions a student writes in a computer program and the visual results of that code is another fundamental element of how students learn. “An important part of becoming a good learner is learning how to push out the frontier of what we can express with words,” Papert writes (p 96). Essentially, he’s arguing that part of expanding what a student knows is forcing them to encounter the edges of their explanatory powers: the link between code and image is itself pushing that expansion. When a student’s words are insufficient to explain what he or she knows, a key element of the learning process is acquiring new words, new concepts, and new grammars to explain it. And when there is such an intimate link between the new words (code) and the concepts they express (the program output), the boundaries of what the student can express expand.
The illustrate this point, consider another example from the LOGO Foundation’s web page introducing the basics of the language. After explaining foundational concepts like how to draw a line and a square, the example introduces how to combine and repeat instructions to create a picture made by iterating a a drawing of a square over and over on top of itself, creating a pinwheel design that is difficult to describe in pure words, but which explodes onto the screen with just a few lines of code:
(Screen grab from LOGO foundation site.)
Papert’s walks through several different analogies for how computational thinking can illuminate instructional situations. There’s an extended discussion of how learning to juggle is a process of “debugging”–correcting many small isolated errors to get a sequence of actions to work. There’s explanations of how computer environments to shape better physics instruction that helps students make connections between physical principles and their own experience of objects in the world–as opposed to simply forcing them to encounter physics through a set of abstract equations. But he also anticipates criticism of this push for teaching “computational thinking” with a powerful argument for how it expands cognitive ability:
In my view a salient feature of human intelligence is the ability to operate with many ways of knowing, often in parallel, so that something can be understood on many levels. In my experience, the fact that I ask myself to ‘think like a computer’ does not close off other epistemologies. It simply opens new ways for approaching thinking. … But true computer literacy is not just knowing how to make use of computer and computational ideas. It is knowing when it is appropriate to do so (p 155).
And perhaps most importantly, Papert believes that the process of learning computational thinking is necessarily a social process that facilitates and depends upon the interplay between student, learning objective, and teacher. Again, the process of debugging is powerful because it re-writes concepts about what it means to be “wrong” and helps students think metacognitively, but it also creates questions and topics of conversation for student/teacher interactions, where the student practices pushing out the frontiers of what he or she can express with words.
“In my vision the computer acts as a transitional object to mediate relationships that are ultimately between person and person,” Papert writes in one of the concluding chapters (p 183). In this case, Victor’s essay on Learnable Programming did just that: a maze of networked computers served up his ideas and enthusiasm for Mindstorms, and hopefully I’ve been able to capture some of that excitement for you, dear reader, on your computer.