In Mindstorms, Seymour Papert argues for the importance of body syntonicity in learning programming.
In many programming languages, the first program you write is “Hello, world!” Which prints Hello, world! at some kind of command line (probably a REPL). It’s really very simple in many of the very-high-level languages people learn these days:
puts "Hello, world!" in Ruby or
"Hello, world!" at the REPL—which simply returns Hello, world!.) It’s also really not very interesting. If all you know is that this is your first program, do you have any idea what your second one will be?
Logo and its progeny, instead, tend to lead with graphics, in no small part because pretty graphics are pretty interesting. Processing’s version of “Hello, world!” — hosted helpfully at https://hello.processing.org — instead entails drawing a rectangle on the screen:
rect(250, 200, 150, 100);. Before Dan Shiffman can even finish writing this first line of code in Processing, he has to explain what a canvas is, how graphics coordinates work, what arguments are, and rules about Java’s syntax — every line has to end with a semicolon. That’s a lot of overhead before writing your first line of code. Meanwhile, it’s probably pretty clear what
rect does if we know we’re in graphics-land, but that series of four numbers is pretty inscrutable. (Also, functions that take four arguments feel like code smells to me; Processing/p5.js’s
Perhaps the biggest problem with Processing’s — and also p5.js’s — approach to starting with graphics is that it already lands you in the abstract world of Cartesian(ish) coordinates. Granted, Processing is largely oriented at older learners, who presumably have suffered through 10th grade geometry.
(x, y) coordinates are probably familiar enough to most people by the time they open the Processing IDE. And while, to be fair, you could absolutely start with “Hello, world!” in Processing —
text("Hello, world!", 100, 100); would draw Hello, world! at
(100, 100) — we’d still have to use
(x, y) coordinates, and so would still have to do much of the same explaining Shiffman does.)
So this isn’t ideal.
Instead of drawing a rectangle for its first program, Logo typically wants us to draw a square. But already, Logo’s square is a computational problem-solving exercise. We start with a single line of code:
FORWARD 50. Which moves our turtle up 50 pixels. (That said, we don’t actually need to know what a pixel is to understand that
FORWARD 50 moves the turtle forward by 50 somethings.) Now, of course,we get to a question: what do you do next if you’re going to draw a square after you’ve moved forward? If you don’t know, get up out of your chair and start walking in a square! First you move forward 5 paces. What do you need to do next? You turn
RIGHT 90 degrees. Then what?
You can do this exercise, as Papert did, with young kids. And you’ll end up with a pretty simple program:
(Note that if your learners don’t have enough geometry yet to understand degrees, we can explore how many units we need to turn right as a kind of trial and error. If you want to follow along and play with this a bit, you can head over to the web-based Logo interpreter [which, I should add, is not without its bugs]. The first image in this post is an illustration of this particular program.)
Because drawing a square is already a problem rather than an instruction, we start asking questions right away. (Or rather, we continue asking questions, because we’ve already begun our question-and-answer session getting the square on the screen.) Once the square is drawn, two paths seem open to us immediately: From a programming perspective, we can pursue an analysis of the repetition in the code we just wrote. It is obvious, and will probably already be irritating, especially to older learners. (That irritation is good; we will use it to drive forward our teaching.) And so we can ask what patterns we see. For example, if the pattern is
FORWARD 50 RIGHT 90, why don’t we have a last
RIGHT 90? What does that last
RIGHT 90 do? Do we want to add it in to our instructions for drawing a square? Why or why not? And what more general lesson might we draw from it? And so, if we’re feeling especially eager to start working with more advanced constructions right away, we might introduce Logo’s
REPEAT function, and get to
REPEAT 4 [FORWARD 50 RIGHT 90] pretty quickly. And from there launch into how Logo names procedures (read: functions), and create, after only a very little while and with a bare minimum of overhead, a procedure that draws a square:
TO SQUARE :SIZE
REPEAT 4 [FORWARD :SIZE RIGHT 90]
So that’s possible, even plausible. But if we’re good pedagogues, we probably won’t do that yet, even with older learners who might be able to handle that kind of abstraction out of the gate. Instead, what we should do is ask: what kinds of things can you draw with your turtle moving forward and making turns? What do you want to draw? If you can’t figure out how to draw it, how might you go about figuring that out?
Mathematically speaking, there’s a difference between the base geometries of Logo and Processing: Processing is Cartesian, Logo is polar. Processing wants its geometries expressed in
ys. Logo wants to know which way to point and how far to go. Processing leads with the idioms of computer graphics; Logo leads with our bodies. Now, the translation between them is fairly straightforward if you’ve got trigonometry. But because the mathematical formalization and manipulation of polar coordinates requires trigonometry, it ends up coming fairly late in our standard math curricula. (Or at least it did when I was in school in the latter decades of the last millennium. And it’s not exactly friendly to humanities and arts students who have probably forgotten or repressed all that.) Phenomenologically speaking, however, there’s an enormous, even insuperable, qualitative difference. The Cartesian view is a God’s-eye view, a view from everywhere and nowhere. (It is not an accident of intellectual history that the man who wrote the Meditations also invented our modern conventions for working with abstract space.) In other words, to visualize and imagine Cartesian space, you have to imagine that you’re God, with everything fully and equivalently visible on a plane extending infinitely in all directions.
Logo’s polar geometry, instead, is a view-from-here. How far do I go? Which way do I turn? It is the geometry of lived space.
Logo’s polar geometry, instead, is a view-from-here. How far do I go? Which way do I turn? It may require cosines and sines and angles indicated by Greek letters to formalize this geometry and manipulate it mathematically. But it is the geometry of lived space. (The most powerful philosophical discussion of this fact that I know comes in Maurice Merleau-Ponty’s discussion of Descartes in his remarkable essay, “Eye and Mind.”) Because of that, it is dead easy to translate the turtle’s problems into problems that you can actually embody, and thus understand. This is what Papert means by body syntonicity: it’s possible to model the computational problems at hand with your body. If you don’t know what to do next, put yourself in the place of the turtle. Get up and walk around, or, if that embarrasses you — as it surely will embarrass university students — turn and tilt your head, or draw on a piece of paper. Brett Victor calls this identifying with the turtle. It’s an enormously powerful idea.
Allow me a brief detour here. Why is the turtle called the turtle? In the opening image, we see a shaded turtle; in the web-based Logo interpreter, it’s an outline of a turtle. In the original Logos of the 1980s, it was a little green triangle. In my own rough draft of Logo-in-JS, it’s a translucent gray triangle.
They look like cute little turtles! And because of that, they got named turtles. And when Logo brought interpreted, live programming with its read-eval-print loop (REPL) to screen-based drawing, this little guy’s screen surrogate was also named a turtle.
Logo’s screen space is based on embodied space, using physical abstractions. The path the turtle draws was originally made by a pen on a piece of paper. And so, Logo’s first microworlds enfold the abstraction of representing 3D movement through a world as a path on a 2D surface. But that abstraction is one that just about everybody sitting in front of a computer has already learned and embodied by using a pen (pencil, marker, crayon) on paper. With Logo, it’s not turtles all the way down — it’s embodiment relations all the way down.
Admittedly, this may seem like it’s a pretty narrow, and slightly wonky technical discussion about how to teach the very first steps of beginning programming. But there are two ideas that are often occluded in discussions of programming pedagogy outside of specialist circles and are even more often occluded when we talk about why we might want to learn to program computers. I get the sense that they are often dismissed out of hand as humanistic namby-pamby these days. (Although to be sure, Papert’s formulation of why computation matters is deeply humanistic.) It’s worth drawing them out.
First, there’s a question of actual pedagogy, which is to say curriculum design. Logo dispatches with imperative instruction — write this line of code and press return — nearly immediately, and with almost no friction. On the one hand, in place of
console.logs, we’ve got
RIGHT. Which is to say, we have actions that we know how to perform ourselves — and that we know how to combine in ways that interest us. Even in that most canonical and intellectually-driven version of learning to program, Abelson and Sussman’s Structure and Interpretation of Computer Programs, we start programming at a Scheme REPL using numbers and practicing arithmetic. Logo’s innovation is that it starts with activities that are richly embodied from the first, and whose abstractions are resolutely familiar. Because of that, we can proceed directly to computational problems and solutions — abstraction, iteration, conditions, recursion — without additional instruction. Which is to say, as a teacher using Logo, I can start immediately into a Socratic question-and-answer without having to ensure: (1) as with Processing, that my students have mastered the arbitrary-seeming abstractions of syntax and Cartesian geometry necessary for a first action to take place; and (2) as with “Hello, world!,” that my students have enough context to understand the interest of programming.
Second, there’s a question of what we might call the phenomenology of computation. (There’s a strain of media theory that suggests that computation has no phenomenology, only ontology, but I think it’s wrong, if productively so.) This is the question of how we mediate, as thinking and embodied creatures, between computation and embodied life, and how computation itself models and mediates embodiment. In other words, how do I, as a learner, and eventually a programmer, grasp the abstractions that computation demands of me? What Logo does is acknowledge that these abstractions are always grounded in lived experience, no matter how far removed from my lived embodiment they may be (and how silly the analogies may be to return them to my lived embodiment). And so it begins its abstractions, its processes of forming abstractions, and its processes of mediating between abstraction and embodiment, very close to the ground. So simple a child can do it.
There are thus two lines of inquiry that open from even this very preliminary investigation of first programs in a variety of different environments.
The first is a theoretical question about the relationship between embodiment and thinking, and how we live through our experiences with computation. The ways I know how to approach this are formal and phenomenologically, which means spending some real time working with computational environments, including Logo but also including SICP and its offspring.
There’s a third line of questioning, too, that is also a concern here: if Logo got so much right, how did we get where we are now? (On one hand, Processing took Logo as one important point of reference; on another, something of Logo’s spirit survives on in Scratch, about which more later; on yet another, so far as I can tell, another something of Logo’s spirit, along with that of SICP, lives on in Racket and Pyret.) We have some ready-to-hand answers in the historical archive around Logo, and they turn on the imperatives of capitalism: to teach people how to consume personalized computation and software objects; to train people for jobs as programmers, ensuring that programming pedagogy stay resolutely practical; to deskill those high-paying jobs as much as possible; and to develop and monetize large-scale, addictive, and/or opaque software systems.
Each of these three lines of inquiry are important, and each in some way are the starting points for this project. I’ve yet to figure out where they go, or how they braid together. I’m excited to find out.