<HTML>
<HEAD>
<TITLE>The Role of Logo in Secondary and Post-Secondary Computer Science</TITLE>
</HEAD>
<BODY>
<H1>The Role of Logo in Secondary and Post-Secondary Computer Science</H1>
<CITE>Brian Harvey<BR>University of California, Berkeley</CITE>
<P>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.
<H2>High School Computer Science</H2>
<P>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 <EM>science</EM> 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.
<P>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.
<P>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.
<P>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.
<P>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.
<P>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!
<P>(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.)
<H2>University Computer Science</H2>
<P>At the university level, the situation is different, because we <EM>are</EM>
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.
<P>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.
<H2>Logo and Computer Science</H2>
<P>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.)
<H2>Logo versus Pascal</H2>
<P>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.
<P>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.
<P>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.
<P>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.
<P>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.
<P>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.
<H2>Logo versus Visual Programming</H2>
<P>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.
<P>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.
<P>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.
<P>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.
<H2>Logo versus Scheme</H2>
<P>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].
<P>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 <EM>name</EM> 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.
<P>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]
<P>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:
<OL>
<LI>
A lexically scoped language can be compiled more efficiently.
I agree with this one, although the same could be said for many
ways in which Lisp dialects value high-level programming over
ease of compilation.
<LI>
Lexical scope is necessary to support Scheme's first-class
procedures. This one is also true. On the other hand, even in
Scheme, not every programming project requires the use of
first-class procedures -- otherwise we wouldn't be able to do
anything in Logo!
<LI>
Lexical scope prevents "name capture" bugs, in which a procedure
written to use a global variable, for example, may unexpectedly find
itself using some other procedure's local variable instead. I don't
give much weight to this argument, although it's the first one that
most computer scientists would mention. It's true, but it's a
Pascal-like argument: Let's weaken the language because a stronger
language allows the programmer to make mistakes.
</OL>
<P>And here are my arguments in favor of dynamic scope:
<OL>
<LI>
Debugging is easier, especially for beginners. In Logo, it's
possible to ask for an automatic <CODE>PAUSE</CODE> 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.
<LI>
Dynamic scope allows for first-class expressions, so a Logo
programmer can invent new control structures like
<CODE>WHILE</CODE> or <CODE>FOR</CODE>.
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.
</OL>
<P>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.
<H2>References</H2>
<P>Abelson, Harold, and Gerald Jay Sussman with Julie Sussman. <CITE>Structure and
Interpretation of Computer Programs</CITE>, MIT Press/McGraw-Hill, 1985.
<P>Harvey, Brian. "<A
HREF="bridge.ps">Symbolic Programming vs. the A.P. Curriculum</A>," <CITE>The
Computing Teacher</CITE>, vol. 18, no. 5, February, 1991.
<P>Harvey, Brian, and Matthew Wright. <CITE><A
HREF="simply-toc.html">Simply Scheme: Introducing Computer
Science</A></CITE>, MIT Press, 1994.
<P><ADDRESS>
<A HREF="index.html"><CODE>www.cs.berkeley.edu/~bh</CODE></A>
</ADDRESS>
</BODY>
</HTML>