Logo is perhaps most famous as the language used to program a robotic turtle. The turtle is physical or virtual, moving around a floor or a screen. As the turtle moves, it leaves a line along its path. A Logo program describes patterns of movement, usually instructing the turtle to draw a picture.
But turtle graphics, as these drawings came to be known, are only one application of the language. Logo has been used to play music, build games, teach college-level computer science, and simulate distributed systems like ant colonies and slime molds.1 Meaning to write a Logo interpreter, I went in search of a specification for the one language, Logo. What I found instead were many Logo-like languages.
Logo-like languages are organized around a belief that people learn best by making things, especially things they care about.2 A turtle graphics program is written by someone who wants to draw a picture. A simulation is written by someone exploring the effects of changing an ant’s behavior. Incidentally, the programmer comes to learn about geometry and distributed systems. But the focus is on doing the thing, making it work.3
Does this mean that the use of the language is more important than the language itself?4 Are there no Logo-like languages, only Logo-like ways of using a language? I can also write JavaScript to draw pictures, play music, build games, and simulate ant colonies. But does JavaScript, used this way, replicate the Logo learning experience? The design of Logo-like languages hint that the experience is not the same.
Logo-like languages model abstract systems in terms of concrete objects that the programmer identifies with.5 To draw a picture with JavaScript, I might instruct the computer to render a path between two points. When I draw a picture with Logo, I give directions to a turtle. If I am uncertain how to instruct the turtle, I can think of myself as the turtle and consider the movements I would make. It’s harder to think of myself as a path or a point.
The dialects of Logo are filled with these objects. Musical programs coordinate a small set of “voices”. Ant colonies (and many other forms of emergent behavior) are simulated by manipulating “chemicals” and “patches” of ground, and a thousand more turtles. Logo programming is not just about making things. Logo programmers enter “microworlds” where these objects exist. What they experience in the microworld is the basis for insights into their own world that arise from Logo programming.
If “Logo-like” is a real distinction of language, and not just a spirit in which any language can be used, then microworlds are a key component of that distinction. But I remain uncertain that the distinction can be made.
I experience all programming languages as microworlds. Function closures and asynchronous control flow need not be personified—they are the texture of the world, like the rising and falling of the tides, or weather patterns read in the clouds. Functors feel no less concrete to me than turtles, but they are structures I navigate rather than agents I command. I do not think of myself as a closure or a functor, unlike the Logo programmer and the turtle, but the elements of a language are features of a world I inhabit:
- Environments are values floating above my head. I have an urge to glance up when I’m thinking about what’s in scope.
- A closure is a one-way tunnel or pipe or wormhole back into the function environment. But the program itself can’t flow through the pipe.
- Asynchronous control flow is a stream that I imagine myself floating down. I think about where the stream will take me.
- Functors are giant structures, like a sculpture by Richard Serra. Functor operations act like cranes, helping me to move around those structures.
I would not use those images to explain those topics to someone else. They are a form of private monologue, like dreaming or talking to yourself. Nor do I defend their correctness as anything other than personal.6 I offer them here only as evidence that a Logo-like experience, where the programmer has an embodied presence in the program, is my common experience of programming.
Is this experience, associated with Logo, not just one potential of programming in general? Perhaps it came to be identified with Logo because Logo was the first language situated in a culture prepared to notice and celebrate it. I’m drawn to this culture because it affirms what has been true for me about learning and programming. But I haven’t needed a Logo-like language to find those same truths.
-
Mindstorms by Seymour Papert is perhaps the best introduction to Logo. The Logo Manual by Hal Abelson, Nat Goodman, and Lee Rudolph is a technical overview of the language, including the turtle and music programming components. Minds in Play: Computer Game Design As A Context for Children's Learning by Yasmin B. Kafai is about building games with Logo. Turtles, Termites, and Traffic Jams: Explorations in Massively Parallel Microworlds (Complex Adaptive Systems) by Mitchel Resnick, is about StarLogo, a Logo dialect designed for exploration of large distributed systems. Bryan Harvey's Computer Science Logo Style series uses Logo to introduce fundamental topics in computer science.
-
Many of our richest learning experiences grow out of situations in which we are engaged in designing and constructing personally meaningful things.
-
Life is not about “knowing the right answer”—or at least it should not be—it is about getting things to work!
-
This is acknowledged to some degree:
Secondly, we believe that the syntactic details of a computer language are of insignificant importance compared to considerations of how the language is used.
A good starting point is to ponder what the several projects described in the chapters have in common. What makes them all Logo projects?
An easy answer might seem to be that they all use a programming language called “Logo.” They do, but this is not enough to qualify, for when you read the chapters you will see that what is important to the writers is not the programming language as such but a certain spirit of doing things: I (and again I guess all the authors) would see many projects that use Logo as thoroughly counter to the “Logo spirit.” And, in the other direction, I can imagine, though I have seldom seen, computer-based projects comparable in spirit and scope to those described in this book which use a different programming language.
But Papert also warns against thinking that all tools are the same:
…two complementary fallacies that have contributed significantly to limiting thinking about the role of technology in education. The “technocentric fallacy” is illustrated by questions like: “How do computers change the way children learn?” Such questions must be rebutted rather than answered, for example by noting that computers don't change anything—people do—and people can use computers to quite different effects just as writing is used to very different effects in pornography and in romantic poetry. But a too-easy rebuttal leads into a complementary fallacy: the ”just-a-tool fallacy.” By this I mean the failure to distinguish between tools (reasonably described as “just tools” that improve their users' ability to do pre-existing jobs, and another kind of “tool” (of which this book offers an excellent example) that are more than “just tools” because their role in the creation of a job nobody thought to do, or nobody could have done, before.
-
Children can identify with the Turtle and are thus able to bring their knowledge about their bodies and how they move into the work of learning formal geometry.
Turtle geometry…adds a new element to Polya's advice: To solve a problem look for something like it that you already understand. The advice is abstract; Turtle geometry turns it into a concrete, procedural principle: Play Turtle. Do it yourself. In Turtle work an almost inexhaustible source of “similar situations” is available because we draw on our own behavior, our own bodies.
So as I designed object-oriented features in StarLogo, I was not terribly concerned with advanced object-oriented features, such as inheritance hierarchies. I was more interested in providing users with good “objects to think with.” I wanted objects that would encourage and support certain types of explorations (in particular, explorations of decentralized systems and self-organizing behaviors). I wanted the objects to be familiar enough for users to relate to, and general enough to support a diverse set of projects.
-
Piaget has demonstrated that children learn fundamental mathematical ideas by first building their own, very much different (for example preconservationist) mathematics. And children learn language by first learning their own (“baby talk”) dialects. So, when we think of microworlds as incubators for powerful ideas, we are trying to draw upon this effective strategy: We allow learners to learn the “official” physics by allowing them the freedom to invent many that will work in as many invented worlds.
Children do not follow a learning path that goes from one “true position” to another, more advance “true position.” Their natural learning paths include “false theories” that teach as much about theory building as true ones. But in school false theories are no longer tolerated.
And I would say adults too.