I was asked to talk about "the role of Logo-like learning of programming in computer science education." The trouble is that I'm not sure I know what "Logo-like" means. It's an interesting word; as soon as we hear it, we all feel as if we know more or less what the person who says it means. We don't have the same urge to interrupt that we would if someone said, for example, "recursion-like." But do we really understand each other? It gets a little fuzzy, for me, when I think about it in more detail.
Let me give a couple of examples. First, I notice that in the conference announcement, the programming language ISETL is considered to be Logo-like. But in 1976, Seymour Papert dismissed APL, which is in many ways similar in spirit to ISETL, by referring to "languages of the BASIC/APL/FORTRAN family" [Pap76]. Logo, APL, and ISETL are all interactive languages that support recursive functions and are designed around mathematical ideas rather than around computer hardware capabilities. Logo is different from the other two in that its mathematics is meant to appeal to young kids, while both APL and ISETL present a more conventional, adult mathematics. What has changed to make APL non-Logo-like in 1976 but ISETL Logo-like in 1993?
As a second example, I'm not sure that my own work, even when I use Logo, is really "Logo-like." In Seymour's new book he characterizes the spirit of Logo as a promotion of Concrete Operational thinking from an interim stage of development, one that should be discarded as soon as possible, to a mode of thinking that is at least as valuable as Formal or abstract reasoning, even in adulthood. [Pap93]
When I read that, I was reminded of the history of the Logo IF notation. The early dialects of Logo, up to the MIT Logo for the Apple and its Terrapin descendents, use a BASIC-like IF-THEN notation:
IF :X < 0 THEN PRINT "NEGATIVE
I was part of the design team for Apple Logo, the first LCSI product, and I was, as much as anyone, responsible for the shift to the notation in which IF is a procedure with two arguments, a true-or-false value and a list of instructions:
IF :X < 0 [PRINT "NEGATIVE]
Our argument was that Logo should have a single, uniform rule for evaluating expressions: Every expression consists of the name of a procedure, followed by some number of expressions that provide the arguments. Logo evaluates those subexpressions, then invokes the named procedure with their values as its argument values. The advantage of the uniform notation is that it paves the way to user-defined control structures like
WHILE [:X < 0] [PRINT :X MAKE "X :X+5]
But there's no question that the LCSI syntax requires some explanation for beginning Logo programmers. By making this change, have we put general rules -- abstract thinking -- above the concrete specificity of IF/THEN? Was this a non-Logo-like change? LCSI is Seymour's company, and they still use the newer IF syntax.
Both of these examples raise the question of what constitutes a Logo-like language. I was asked to address a somewhat different question, about Logo-like learning. But I'm just as confused about what that means. Let me describe two of my own experiences as a teacher, and let's ask to what extent each of them is "Logo-like."
The experience I enjoyed most, and of which I'm proudest, was running a computer lab at the Lincoln-Sudbury Regional High School, in Massachusetts, from 1979 to 1982. It was never completely clear what I was supposed to teach. The principal, who came from a business background, talked about "data processing." Some of the other teachers had picked up on the recently invented phrase "computer literacy." Computer science as a high school subject didn't really exist yet; I was myself most interested in computer programming, especially systems programming. The students, too, had a broad range of interests and expectations when they signed up for a computer course.
At first I tried offering different courses for students with different levels of interest, but I soon learned that most students didn't really know what they wanted until they had some experience within the courses. (Remember that personal computers had just barely been invented, and most students had no idea what it meant to use a computer, or to program one.) I ended up using a self-paced structure, in which there was one course for everyone, but each student could design his or her own curriculum within broad limits. Logo programming was one of the options. Every beginner was required to learn a little Logo and a little word processing; beyond that, anything was allowed.
We had a Unix-based timesharing system. At that time, Unix provided programming languages and application software far in advance of anything available on personal computers, such as the Apple II and the Atari 800. Partly because of Unix, and partly because I was spending much of my own time on system software development, the kids soon got the idea that the adult programming language was C, and so that's what all of the really interested students used. C is about as far from a Logo-like language as you can get! The C programmer deals very directly with issues of data representation within a computer, such as word length and memory allocation.
On the other hand, what felt "Logo-like" about this situation was that the kids were engaged entirely in real work, using the computer for their own goals and not jumping through assigned hoops. (Some students took on the task of helping with the school's administrative computing; this work was somewhat less self-directed, but even more real, than the student-initiated projects.) A lot of effort went into video games, using the limited character-based graphics of the VT-100 terminals. One student wrote an EMACS-like text editor, called JOVE, that's still widely used at Unix sites. Not all students took to programming, but many more learned to use the word processing facility for their papers for other classes. (One year I had three or four students who were also taking a chemistry class, in which the teacher had said they could bring one page of notes into the final exam. These students collaborated on designing and printing a page, using the smallest available font, to cram in all their notes!)
One reason that Logo itself wasn't popular among these students was the technical limitations of the facility. Graphics terminals were very expensive in those days. We did have a few Atari 800 computers that we used as graphics terminals (Atari Logo hadn't been invented yet), but they could only handle 40-column text, so they weren't good for much other than graphics. The Logo interpreter we cobbled together for Unix was very slow. There was no hardcopy graphics capability. We did also have some Terrapin floor turtles, but they were unreliable.
Another Logo-like aspect, however, was the social interaction in the lab. There was no formal class time; people would come and go to use the machine or just to hang out. An organization of students took responsibility for running the lab, and its members were given keys to the room so that they could use the machine without supervision evenings and weekends. (Nothing was ever stolen, and there was very little breakage.) Kids set up their own working partnerships; more experienced kids taught newcomers. Most of my effort went into this meta-curriculum rather than into teaching programming. It didn't always go smoothly; there were fights, violations of privacy, and the like. But we all saw these problems as community problems, not just as something for me, the teacher, to deal with.
(To make this focus on community sound a bit more serious, and perhaps more "Logo-like," let me discuss it in Piagetian terms for one paragraph. By high school age, kids are supposed to be at the highest stage of cognitive development, the Formal Operational stage. In a certain sense, there is nothing more for them to learn, cognitively. On the other hand, high school kids are still far from the top of the scale in moral development. So it makes sense that issues of community and responsibility should be central to their education.)
To sum up, my high school computer lab felt to me very much a Logo-like learning environment, although Logo itself was a minor component, and although many of its characteristics are ones that Seymour Papert lists as non-Logo-like: the equipment was concentrated in one room, the curricular focus was on computing rather than on math or other areas, and the style of work was primarily the formal, abstract, goal-directed style that Seymour criticizes as male-oriented.
I currently teach undergraduates at the University of California at Berkeley. Our introductory computer science course was developed at MIT [Abe85]; one of the developers is Hal Abelson, a Logo old-timer who led the first microcomputer Logo development projects for the TI 99/4 and the Apple II. The course uses Scheme, a dialect of Lisp that's similar to Logo in many ways. (At Berkeley we've even modified Scheme to add the Logo word and sentence primitives, so that our students can write Logo-like language processing programs.)
Is this course Logo-like? How I feel about that question depends on my standard of comparison. In a recent paper [Har91] I compare the Abelson and Sussman course with more traditional, Pascal-based, software engineering courses; by that standard, our course feels very Logo-like indeed. The traditional course is full of commandments about programming style, telling students what they should and shouldn't do. The traditional course must spend a lot of time on programming language syntax; our (dare I say) Logo-like language has a simple syntax that takes hardly any instructional time. Students work on programming projects that are designed to illuminate big ideas in computer science: ideas that help the students write programs, rather than abstract theoretical ones.
But compared to my high school experience, this course doesn't feel Logo-like at all. The style is very different, first of all. I give lectures to groups of 300 students. Then the students go to the computer lab to do their assigned projects, but I'm generally not in the lab with them. (We do have teaching assistants in the lab at scheduled hours.) The projects are assigned, rather than student-initiated.
In the six years I've been at Berkeley, I've taken some small steps toward a learning environment that feels slightly more Logo-like. For example, we used to assign weekly homework with exercises from the textbook. Now I assign the exercises, but don't collect them, so that it's clear to the students that the exercises are for their own benefit and not for evaluation purposes. I've instituted cooperative learning, redesigning the programming projects to be done by groups rather than by individual students. These are very tiny steps to be discussing at a Logo conference! But they go very much against the grain of the context within which I teach. The introductory course is part of a curriculum ladder, and later courses depend on "covering" the curriculum. The students, in these bad economic times, tend to be much more worried about competing for jobs than about learning.
The irony in all this, as we'd expect from our Logo experience, is that the students who end up doing best, even in the job market, are the ones who can find the courage to forget about jobs and grades and jumping through hoops, and treat my course as if it were a more Logo-like environment, getting excited about the new ideas and pushing beyond the required work to invent and explore new programming techniques.
When I was an undergraduate myself, I was lucky enough to fall in with the gang at the MIT Artificial Intelligence Lab, which was for me the perfect prototype of a Logo-like environment even before there was Logo. On the one hand, everyone was engaged in real work, pushing the state of the art in computing, but on the other hand, nobody felt any pressure about it. It was all for fun; you could try anything, and if it didn't work out, you just tried something else. (But don't forget that the hacker spirit at that lab is also the prototype of the style of work that Papert and Turkle call androcentric.)
After this long preamble, I think I'm ready to talk about the question in the title of this paper. There are two different ways of looking at a computer science lab that both seem connected somehow to the Logo-like scale. The more obvious one is about style of work; as I've been saying, from that perspective, my high school lab felt extremely Logo-like, and my university course doesn't. This is the question that I've inadequately represented as "Fun vs. Professionalism" in my title.
The other is the more technical question about curriculum and programming language. There is a very sharp distinction between the software engineering approach and what I think of as the artificial intelligence approach. In the software engineering approach, students are being trained primarily to be disciplined in their programming style, so that their code can easily fit in with other people's code. The curriculum is full of rules; the programming language used is always one with strong typing and similar restrictive rules. Software engineers talk about object oriented programming, for example, primarily as an advance in information hiding: An OOP language is one in which procedures as well as data have very tightly limited scopes. The AI approach replaces this moralistic tone with the cultivation of a sense of wonder at the ways in which thinking harder about programming can pay off in increased expressiveness. In this approach, there isn't one correct way to program, but rather a world full of programming styles and structures, each one appropriate for certain kinds of problems. On this view, for example, object oriented programming is about a metaphor, expressing a kind of parallelism in which each datum has its own intelligence, rather than about discipline.
This division, the one I've called "Symbolic Programming vs. Software Engineering," is fundamentally about the philosophy of computer science. It seems quite different from the question about style of work, but I think I can find some similarities.
One difference between a Logo microworld and an ordinary piece of educational software is that in the Logo version, the program itself is available for inspection and modification, not a black box. In the study of computer science, a programming language is itself a microworld. That's why the Lisp tradition of introducing even beginners to the workings of the Lisp interpreter is Logo-like: By examining and modifying the interpreter, we turn the Lisp microworld into a glass box instead of a black box.
A crucial part of a Logo classroom is that the learners have permission to explore using their own individual styles. There isn't just one right way to program. Similarly, in the symbolic programming approach to teaching computer science, there is no orthodoxy about top-down structured programming. Top-down is one fine approach, but so is tool-building without a specific goal in view.
Symbolic languages, and languages with relaxed attitudes toward data types, allow for programming projects about sentence generation, carrying on conversations, the automated psychotherapist, and so on. These projects are very much in the Logo tradition, and in contrast with the heavy emphasis on numeric computation that's typical of the software engineering languages.
Finding these examples in which the technical details of a programming language and a curriculum seem to be connected with working in the Logo spirit gives me the courage to return to the question of languages and hope that in so doing I'm still addressing the question that was given to me.
In my 1982 Byte article, I listed several characteristics that seemed to make Logo special. [Har82] Let me go through the list and comment on where we stand in programming languages today.
Procedural. We seem to have won this battle. Even BASIC, in its modern dialects, allows a modular program structure. In fact, procedural languages are now the right wing of language design, in contrast with newer approaches such as functional, object-oriented, and logic programming. Some recent versions of Logo address the issue of parallelism, although that newer Logo technology is not yet, I think, widely understood among the people actually using Logo in schools.
The issue today that corresponds to the one about procedural programming languages a decade ago is that many people don't want to deal with languages at all. Instead, modern software provides a graphical user interface, with mice, buttons, menus, and so on. Even Logo has not ignored this trend; LogoWriter on the Macintosh is full of immediate-mode graphical controls for things like moving and turning the turtle by hand. I think the battle we have to fight is to maintain the position that immediate-mode control isn't enough, because it doesn't allow for the abstraction of regularities and patterns of work. There must be a way to create control structures that can carry out the same operations that can be performed graphically.
Interactive. This is a crucial issue, and the terms of the debate have changed dramatically in recent years. Originally, there was a clear-cut distinction between interactive languages such as Logo, Lisp, and BASIC, and non-interactive languages like C and Pascal. The style of work in the non-interactive languages was awful. Programmers had to write their programs in an environment entirely separate from the language itself, then go through a compilation process, and finally run the program, often with no runtime support for debugging or modifying the program. Their excuse was that a compiled program runs much faster than an interpreted one, and indeed the Logo interpreters of that time were unpleasantly slow.
The characteristics of the underlying languages have not changed. But today's Pascal or C programmer works with an integrated development system. There is a text editor that understands the syntax of the particular language, so that it can check the form of a program as you write it. There is interactive debugging, generally using a window system effectively so that the debugging information is visually separate from the output of the program itself. You still can't walk up to a C compiler and ask it to print 2+2, and yet today's C programmers are likely to complain that a Logo programmer suffers from an insufficiently interactive working environment! For myself, I still find interaction with the actual programming language more powerful than these auxiliary interactive tools, but I'm not sure whether that's just because I'm accustomed to an old-fashioned style of work. It can certainly be argued that commercially available versions of Logo have moved backward in their provisions for debugging support; Apple Logo allowed the user to enable an automatic PAUSE in case of an error, but LogoWriter doesn't.
Recursive. In the early Logo work, learning about recursion was a crucial step in intellectual development. Ideas like the little person model of procedure invocation were invented mainly to help in understanding recursion. In one sense, this battle seems to be behind us; every modern programming language allows recursion. But the conventional wisdom in computer science education is that recursion is too costly for ordinary use; students are taught to prefer iterative language mechanisms. Meanwhile, except for drawing fractals, Logo users rarely use recursion in a way that couldn't be handled by conventional iterative language constructs. (Indeed, part of my technical work has been the introduction of iterative constructs to Logo.) I think it's still worth remembering that recursion is a single mechanism with remarkable expressive power. For example, these days it's easier to draw a circle in a canned drawing program than in Logo, because the canned program has a dedicated circle feature; but the drawing program can't use its circle feature to draw spirals or stars.
List Processing. Logo is still out in front on this point. Even other dialects of Lisp don't make the manipulation of words and sentences as convenient as it is in Logo. If you want to conjugate a verb or take the plural of a noun, Logo is the language of choice. On the other hand, I think it's still true that most actual Logo users consider list processing to be arcane and difficult. LogoWriter fans often prefer to manipulate text by carrying out a sequence of text editing commands on the representation of the text on the screen, rather than apply recursive functions to the text taken as data. My hope is that a good collection of higher-order functions like MAP and FILTER can make list processing seem more palatable.
Untyped. This is probably where you'll find the most heated arguments between symbolic programming enthusiasts and software engineers. The lack of type declarations in Logo, and in Lisp generally, makes programming enormously easier to learn; the software engineers, though, think it's sinful. The real argument for typed variables is that the compiler can produce more efficient programs, but the theoretical argument is that restricting a variable to a particular type makes for more disciplined programming. (It also makes for ludicrous user interfaces, in cases where the natural thing is to read numbers until the user says something like "DONE" to indicate the end of the numbers. Instead, the typed languages make the user type something like "9999" or "-1" to indicate the end.) Some computer scientists will say that the advent of object oriented programming has settled this question in favor of strong typing, but the example of Object Logo shows that that isn't so.
Extensible. We are beginning to win this battle when it comes to application software. Many large programs these days include a "scripting language," such as Hypertalk as the scripting language for Hypercard. But mainstream programming languages are not generally viewed as bases for building language extensions, except in the sense that you can write a full interpreter or compiler from scratch. This property is still very important in Logo practice, because it's the technical basis for microworlds. Any Logo programmer (not just the implementors at the software companies) can develop an extended Logo with extra primitives for some microworld.
Interesting Applications. New applications are invented very fast these days. Logo is in the lead in some cases (robotics, with Lego-Logo), hustling to catch up in others (MIDI support recently added to Object Logo), and not really in the running for some (real-time animation, unless you have a massively parallel computer on which to run *Logo). The proliferation of special-purpose software tuned to each of these application areas raises the question of whether we can reasonably expect any general-purpose programming language to be a good match in every case. In the old days, the appeal of Logo programming wasn't so much the act of programming itself as the results you could tease out of a computer; today you can get more spectacular results without programming at all. This is why there has been a vast decrease in the amount of time spent on programming in schools in the past few years; students are using application programs instead. Is this good or bad? In a way the issue is similar to the one that we argued about when Sprites were introduced in TI Logo: "It's too easy to get pretty pictures on the screen in immediate mode, so kids won't learn to think procedurally."
User-Friendly. In the old days we made a big fuss about things like the text of error messages and the names of primitives. This tradition is still alive in Logo; the switch from OUTPUT to REPORT in LogoWriter is an example. But a new generation of computer users accustomed to point-and-click interfaces would question the user-friendliness of any Logo environment. I think we have to admit that Logo syntax, although better than Pascal, is still far from transparent. Can we develop more compelling notations without sacrificing the essence of programming? I guess this is what Boxer is about, in part.
No Threshold, No Ceiling. We are starting to see a division of the Logo using community. Products like LogoWriter are deliberately aimed at the young kids who make up most of Logo's actual audience. Object Logo is a high-end version for more advanced programmers. I've found it necessary to implement my own version, Berkeley Logo, just so that there will be a more or less unchanging interpreter for the language used in my books. In principle I suppose this is a good thing, because it allows us to extend the limits of Logo usability in both directions. But I wonder whether Logo's rather small audience can support so many separate development teams.
To sum up, some of the technical issues that seemed important a decade ago in distinguishing Logo from other languages are no longer at issue, such as procedural organization and recursion. Others burn as brightly as ever: list processing and untyped variables. Most interestingly, others have changed into different issues, especially the ones about user interfaces, such as the definition of interactiveness.
Abelson, Harold, and Gerald Jay Sussman with Julie Sussman. Structure and Interpretation of Computer Programs, MIT Press/McGraw-Hill, 1985.
Harvey, Brian. "Why Logo?" Byte, vol. 7, no. 8, August, 1982.
Harvey, Brian. "Symbolic Programming vs. the A.P. Curriculum," The Computing Teacher, vol. 18, no. 5, February, 1991.
Papert, Seymour. "An Evaluative Study of Modern Technology in Education," MIT Logo Memo 26, June, 1976.
Papert, Seymour. The Children's Machine, Basic Books, 1993.
www.cs.berkeley.edu/~bh