First of all, what do we mean by "computer science"? I take it that we are talking about the study of computing as a thing of interest in itself, not the use of computers for practical work or the use of computers in teaching some other piece of curriculum. Beyond these generalities, I think it makes a big difference whether we're talking about high school or university level.
Why should a high school student study computing? Let me start with a negative answer: I don't think it has anything to do with job training. More specifically, the computer-related jobs for which one can be hired directly from high school are not computer science jobs; they're data entry jobs, perhaps technician jobs, perhaps sales jobs. The students who want those jobs need practical experience with computers, but computer science is something different.
I see two purposes for the study of computer science in high school. One is that it provides the basis for a kind of intellectual apprenticeship. It happens that the process of programming a computer is very appealing to many kids; by taking that process seriously, they experience the sort of commitment and pursuit of excellence that other kids get from team sports, from the school newspaper, and so on. The appeal of programming is that a student can achieve real results, using the computer for some real purpose. We as teachers should be happy to encourage our students in this pursuit because along the way they learn about formal language, about refining a rough solution (debugging), about engineering decisions, and many other good lessons.
A second, more specific reason for high school computer science is that it works as a kind of applied mathematics. (Of course this is precisely what Logo people say about the use of Logo by younger children; I'm just extending that idea to older learners.) A programming language is a formal system in the same way that Euclid's axioms are a formal system; the difference is that the programming language is executable. Programming can be an area of application for ordinary school mathematics, too. For example, to implement a turtle graphics system requires an understanding of analytic geometry and trigonometry.
What does this imply about the content of high school computer science? Since our task is to engender in students the excitement of a scientific enterprise, and not to prepare them for immediate employment as computer programmers, I believe that the curriculum must be firmly rooted in what actually appeals to kids: practical programming projects. This means that both the strict programming discipline of the software engineering approach and the formal reasoning of theoretical computer science must not be emphasized, if indeed they are present in the curriculum at all. In fact, there really is no curriculum! I mean that there is no particular fact or skill that every high school computer science student must master. It's fine if each student pursues a unique direction and ends up with very unbalanced learning; that can be corrected later.
Should every student study computer science? I don't think so. Of course every student should know how to use computers! But that's not what a computer science course is about, and I don't think it's what any course should be about. Students should learn to use computational tools along the way, as they write papers in English class or collect data in physics class. I would go further: I think that probably every student should learn something of computer programming, in math class, because writing programs is one good way to study mathematical ideas. But the intense study of computing for its own sake is not necessary for everyone.
At the same time, I do think that every student should have the opportunity to study computer science. In the United States right now, a combination of economic austerity and political reaction has substantially reduced the opportunities for public school students to take elective subjects of any kind. Every topic is either required or not offered for lack of budget. That's a disaster; it means that every kid must fit a single mold. Computer kids should study computer science!
(If we wait for kids to self-select, we'll probably end up exacerbating the underrepresentation of women in computer science. I think we should exert ourselves to solve that problem, but I don't think that requiring high school computer science for everyone is part of the solution.)
At the university level, the situation is different, because we are training people for jobs as computer programmers or as research computer scientists. Therefore, it does make sense to plan a detailed curriculum for those students who choose this career training. I think it should still be clear that the purpose of computer science is to be able to write better computer programs, but theory and discipline do have a place. The trick is to strike a balance, so that the student retains the sense of empowerment from high school, learning the necessary skills without feeling that the skills have taken over from the goal of solving practical problems.
A university computer science department may also offer courses in computer programming for students from other majors. In those courses, I think the focus should not be so much on practical programming skill as on understanding what programming is like. A physicist, for example, who needs a program written should probably hire a programmer. But the purpose of the programming course, for the physicist, is to come away with a better sense of what computers can reasonably be expected to do, and what kinds of things the programmer needs to know about the task in order to do a good job. Also, of course, even for these older learners, programming can just be a lot of fun! The course for non-computer-science majors should respect that sense of fun.
Now we can talk about Logo. I'll consider a Logo-based approach to computer science in contrast to three other possible approaches. (Ten years ago, one of them would have been BASIC, but I think that battle has been won. I'd like to say that we won it, but actually the Pascal people won it for us. Even today's BASIC isn't much like the one we fought against, and even the newer versions of BASIC aren't widely used in serious computer science.)
I've written a paper about this dichotomy [Har91], so I'll just summarize it here. Behind Pascal (and its descendents, such as Modula) is the idea that the main purpose of computer science education is to teach students to restrict themselves to a certain style of programming that lends itself to large-scale collaboration and is defensive against certain kinds of bugs. People who accept this idea choose restrictive languages like Pascal; they also use the word "should" a lot in their teaching. Behind Logo (and other dialects of Lisp) is a very different idea: Both languages and education should open doors, not close them. Students should learn many powerful techniques, not one single technique for all problems. The programming language should keep track of the boring details, so that the programmer can concentrate on the interesting aspects of the problem at hand.
At the high school level, it seems to me that our side is clearly in the right. Everyone bemoans the fact that not enough young people are interested in science; clearly, we should take an approach that will turn them on, instead of off. Also, since programming in a high-level language like Logo is so much easier than using a low-level language like Pascal, Logo lends itself to more advanced projects. For example, the third volume of my _Computer Science Logo Style_ series includes a Pascal compiler written in Logo. I think this program is within the grasp of a bright high school student. A Logo interpreter in Pascal would be a much larger program, and therefore a much harder project. Although this goes against the images of the two languages, I would argue that Logo is more appropriate for serious work, while Pascal is more appropriate to toy problems.
Why is this view not held more widely? I think two things stand in the way. One of them is the general preference of schools for curriculum-based learning rather than project-based learning. There isn't a lot of computer science curriculum in Logo! (Someone should write some competition for my books.) If we use Logo to teach computer science, it's not just to substitute one language for another in a traditional teaching environment. We choose Logo because we want to see student-initiated projects; our classrooms may look like utter chaos to the administrators.
The second problem is more technical. Logo has traditionally been available only in slow, interpreted implementations, with weak input/output facilities. (Logo provides great support for certain special input/output devices, such as Lego blocks, but not general file handling.) Object Logo, with a fast compiler and good support for windows, menus, and so on, is a big step in the right direction. It's really the only Logo around in which students can write computationally demanding programs and expect fast results. We need more such implementations, but the market isn't there; Paradigm is barely staying afloat. I don't know what to do about this chicken and egg problem.
What about Logo versus Pascal at the university level? Here the argument is harder, because many people think students who are being trained for real jobs must learn the languages that those jobs require. These days that means C, not Pascal, but C and Pascal are more or less identical. I think a case can be made for the other side: A professional programmer should be able to learn any language in an hour or so, and therefore it's not necessary that the first language studied be the most popular one. Instead, the first language should be one that lends itself to studying the large issues, by imposing as few low-level details as possible. But this will be a very hard sell.
Of course there is continuing demand for Logo at the university level in courses intended for teacher training, and also it's not so hard to make the case for Logo in the programming courses for non-computer-science majors in general.
A new contender among programming languages is the category of visual or iconic languages. This broad category includes "programming by example" systems used in some application programs, immediate-mode iconic control systems with no real stored-program capability, and programming languages that include more or less elaborate visual interfaces, such as Visual Basic.
In a way, this new group of tools has taken over the position formerly occupied by BASIC. One way to look at those old arguments is to imagine a continuum. At one end, the BASIC end, is a language that's easy for a beginner but with absolutely no attempt at sophisticated program structure; at the other end, the Pascal end, is a language with a lot of formal structure that's impossible to use. In this model, Logo occupies a middle position, trying to provide both easy access for beginners and enough control mechanisms to grow with the learner. Visual programming, like the old BASIC, emphasizes the needs of the beginner.
Visual programming is a tremendously appealing idea. These days, powerful personal computers can carry out complex graphics designs and animations; a beginner can control this power with very little investment in learning a new vocabulary. The trouble is that iconic programming sweeps under the rug precisely the ideas that are central to computer science: control structures, naming, scope, data abstraction, and so on.
In fact this needn't be an either-or choice. Some elements of visual programming have found their way into recent dialects of Logo. For example, Object Logo allows for programmable menu bars and dialog windows; although Object Logo is not itself a visual programming language, therefore, it can serve as the basis for creating one. LogoWriter on the Macintosh has immediate-mode controls for the turtle heading and position. (It would be nice if these operations could be used in a programming-by-example mode so that the corresponding Logo instructions would be added to some procedure.) The new Microworlds version extends the visual appeal with easy access to parallelism. George Mills, at the Digital Equipment Corporation, has embedded my Berkeley Logo interpreter in a graphical interface under Microsoft Windows, thereby creating a language with the flavor of Visual Basic but with the power of Logo inside it.
More within the family, so to speak, is Scheme, the most interesting rival to Logo as a language for computer science. Scheme has several advantages. Some of them are external to the language itself: People take it seriously, because it doesn't have Logo's reputation as a language for little kids; and the best computer science book ever written uses Scheme [Abe85].
Scheme also has some advantages within the language itself. Its fully parenthesized, consistently prefix syntax is more uniform and easier to parse. (Logo's compromise syntax is supposed to be more comfortable for human beings, but in my old age I no longer believe this; I find it easier to read a Scheme program than to read a Logo program. All those parentheses help, especially when supported by a text editor that automates the proper indentation.) Scheme, unlike Logo, has true first-class procedures. (In Logo, the name of a procedure can be used as an argument to something, but not the procedure itself. Logo doesn't have nameless procedures.) Very fast compiled versions of Scheme are available, partly because Scheme's lexical scope is easier for a compiler than Logo's dynamic scope (this is why Object Logo uses lexical scope) and partly because the people who know how to write good compilers are more interested in Scheme than in Logo.
There are two ways in which I think Logo still has an edge. One is the word and sentence operations. Instead of words, Scheme has a lower-level (therefore more efficiently matched to computer hardware, but harder to use) system with separate data types for characters, symbols, numbers, and strings. It is possible to implement an extension to Scheme that closely approximates the Logo word approach, at some efficiency cost. Indeed, a new Scheme-based text of which I am co-author does exactly this. [Har94]
Logo's other advantage, but a controversial one and a mixed blessing, is dynamic scope. Virtually every computer scientist would disagree with me about this, and would consider dynamic scope a weakness. Here are their arguments:
And here are my arguments in favor of dynamic scope:
PAUSE in case of an error. The
result is that you see the error message, you get a Logo prompt,
but the values of all relevant local variables are straightforwardly
available for examination or modification. In a lexically scoped
language, the usual situation is that you have to use a special
debugging language, different from the language in which you wrote
your program, and you have to have a very advanced understanding of
how the language interpreter works in order to find the information
you need.
WHILE or FOR.
This feature serves a purpose similar to that of first-class
procedures in Scheme. Scheme's approach is more general, but
Logo's approach is probably easier for a beginning computer
science student to understand.
My guess is that at the university level, instructors with a Logo-like approach to education will choose Scheme; indeed, I myself have done so at Berkeley. For high school students, I think the choice is less clear. Neither Scheme nor Logo is widely used in secondary education. In communities in which students all learn Logo in elementary school, it's relatively easy to use Logo for high school computer science because the kids already know the language. That may be enough of an advantage to keep Logo alive in that market.
Abelson, Harold, and Gerald Jay Sussman with Julie Sussman. Structure and Interpretation of Computer Programs, MIT Press/McGraw-Hill, 1985.
Harvey, Brian. "Symbolic Programming vs. the A.P. Curriculum," The Computing Teacher, vol. 18, no. 5, February, 1991.
Harvey, Brian, and Matthew Wright. Simply Scheme: Introducing Computer Science, MIT Press, 1994.
www.cs.berkeley.edu/~bh