<HTML>
<HEAD>
<TITLE>Computer Science Logo Style vol 1:Preface</TITLE>
</HEAD>
<BODY>
<CITE>Computer Science Logo Style</CITE> volume 1:
<CITE>Symbolic Computing</CITE> 2/e Copyright (C) 1997 MIT
<H1>Preface</H1>
<TABLE width="100%"><TR><TD>
<IMG SRC="../csls1.jpg" ALT="cover photo">
<TD><TABLE>
<TR><TD align="right"><CITE><A HREF="http://www.cs.berkeley.edu/~bh/">Brian
Harvey</A><BR>University of California, Berkeley</CITE>
<TR><TD align="right"><BR>
<TR><TD align="right"><A HREF="../pdf/v1ch00.pdf">Download PDF version</A>
<TR><TD align="right"><A HREF="../v1-toc2.html">Back to Table of Contents</A>
<TR><TD align="right">[no back]
chapter thread <A HREF="ack.html"><STRONG>NEXT</STRONG></A>
<TR><TD align="right"><A HREF="https://mitpress.mit.edu/books/computer-science-logo-style-second-edition-volume-1">MIT
Press web page for Computer Science Logo Style</A>
</TABLE></TABLE>
<HR>
<P>This book isn't for everyone.
<P>Not everyone needs to program computers. There is a popular myth that
if you aren't "computer literate," whatever that means, then you'll
flunk out of college, you'll never get a job, and you'll be poor and
miserable all your life. The myth is promoted by computer
manufacturers, of course, and also by certain educators and writers.
<P>The truth is that no matter how many people study computer programming
in high school, there will still be only a certain number of
programming jobs. When you read about "jobs in high-tech industry,"
they're talking mostly about manufacturing and sales jobs that are no
better paid than any other manufacturing jobs. (Often, these days,
those jobs are exported to someplace like Taiwan where they pay
pennies a day.) It's quite true that many jobs in the future will
involve <EM>using</EM> computers, but the computers will be disguised.
When you use a microwave oven, drive a recently built car, or play a
video game, you're using a computer, but you didn't have to take a
"computer literacy" course to learn how. Even a computer that
looks like a computer, as in a word processing system, can be mastered
in an hour or two.
<P>This book is for people who are interested in computer programming
because it's fun.
<P><H2>The Intellectual Content of Computer Programming</H2>
<P>When I wrote the first edition of this book in 1984, I said that the study
of computer programming was intellectually rewarding for young children in
elementary school, and for computer science majors in college, but that high
school students and adults studying on their own generally had an
intellectually barren diet, full of technical details of some particular
computer brand.
<P>At about the same time I wrote those words, the College Board was
introducing an Advanced Placement exam in computer science. Since then, the
AP course has become popular, and similar official or semi-official computer
science curricula have been adopted in other countries as well. Meanwhile,
the computers available to ordinary people have become large enough and
powerful enough to run serious programming languages, breaking the monopoly
of BASIC.
<P>So, the good news is that intellectually serious computer science is within
the reach of just about everyone. The bad news is that the curricula tend
to be imitations of what is taught to beginning undergraduate computer
science majors, and I think that's too rigid a starting point for
independent learners, and especially for teenagers.
<P>See, the wonderful thing about computer programming is that it <EM>is</EM>
fun, perhaps not for everyone, but for very many people. There aren't many
mathematical activities that appeal so spontaneously. Kids get caught up in
the excitement of programming, in the same way that other kids (or maybe the
same ones) get caught up in acting, in sports, in journalism (provided the
paper isn't run by teachers), or in ham radio. If schools get too serious
about computer science, that spontaneous excitement can be lost. I once
heard a high school teacher say proudly that kids used to hang out in his
computer lab at all hours, but since they introduced the computer science
curriculum, the kids don't want to program so much because they've learned
that programming is just a means to the end of understanding the
curriculum. No! The ideas of computer science are a means to the end of
getting computers to do what you want.
<P><H2>Computer Science Apprenticeship</H2>
<P>My goal in this series of books is to make the goals and methods of a
serious computer scientist accessible, at an introductory level, to
people who are interested in computer programming but are not computer
science majors. If you're an adult or teenaged hobbyist, or a teacher
who wants to use the computer as an educational tool, you're
definitely part of this audience. I've taught these ideas to teachers
and to high school students. What I enjoy most is teaching high
school freshmen who bring a love of programming into the class with
them--the ones who are always tugging at my arm to tell me what they
found in the latest <EM>Byte.</EM>
<P>I said earlier that I think that for most people programming as job training
is nonsense. But if you happen to be interested in
programming, studying it in some depth can be valuable for the same
reasons that other people benefit from acting, music, or being a news
reporter: it's a kind of intellectual apprenticeship. You're learning
the discipline of serious thinking and of taking pride in your work.
In the case of computer programming, in particular, what you're
learning is <EM>mathematical</EM> thinking, or <EM>formal</EM>
thinking. (If you like programming, but you hate mathematics, don't
panic. In that case it's not really mathematics you hate, it's
school. The programming you enjoy is much more like real mathematics
than the stuff you get in most high school math classes.) In these books I
try to encourage this sort of formal thinking by discussing
programming in terms of general rules rather than as a bag of tricks.
<P>When I wrote the first edition of this book, in 1984, it was controversial
to suggest that not everyone has to learn to program. I was accused of
elitism, of wanting to keep computers as a tool for the rich, while
condemning poorer students to dead-end jobs. Today it's more common that
I have to fight the opposite battle, trying to convince people why <EM>
anyone</EM> should learn about computer programming. After all, there is all
that great software out there; instead of wasting time on programming,
I'm told, kids should learn to use Microsoft Word or Adobe Illustrator
or Macromind Director. At the same time, kids who've grown up with intricate
and beautifully illustrated video games are frustrated by the relatively
primitive results of their own first efforts at programming. A decade ago
it was thrilling to be able to draw a square on a computer screen; today
you can do that with two clicks of a mouse.
<P>There are two reasons why you might still want to learn to program. One is
that more and more application programs have programming languages built in;
you can customize the program's behavior if you learn to speak its
"extension" language. (One well-known example is the Hypertalk extension
language for the Hypercard program; the one that has everyone excited as I'm
writing this is the inclusion of the Java programming language as the
extension language for the Netscape World Wide Web browser.) But I think a
more important reason is that programming--learning how to express a method
for solving a problem in a formal language--can still be very empowering.
It's not the same kind of fast-paced fun as playing a video game; it feels
more like solving a crossword puzzle.
<P>I've tried to make these books usable either with a teacher or on your
own. But since the ideas in these books are rather different from those of
most computer science curricula, the odds are that you're reading this on
your own. (When I published the first edition, one exception was that this
first volume was used fairly commonly in teacher training classes, for
elementary school teachers who'd be using Logo in their work.)
<P><H2>About the Second Edition</H2>
<P>Three things have happened since the first edition of these books to warrant
a revision. The first is that I know more about computer science than I did
then! In this volume, the topics of recursion and functional programming
are explained better than they were the first time; there is a new chapter on
higher order functions early in the book. There are similar improvements
in the later volumes, too.
<P>Second, I've learned from both my own and other people's experiences
teaching these ideas. I originally envisioned a style of work in which high
school students would take a programming course in their first year, then
spend several years working on independent projects, and perhaps take a more
advanced computer science class senior year. That's why I put all the
programming language instruction in the first volume and all the project
ideas in the second one. In real life, most students don't spread out their
programming experience in that way, and so the projects in the second volume
didn't get a chance to inspire most readers. In the second edition, I've
mixed projects with language teaching. This first volume teaches the core
Logo capabilities that every programming student should know, along with
sample projects illustrating both the technical details and the range of
possibilities for your own projects. The second volume, <EM>Advanced
Techniques,</EM> teaches more
advanced language features, along with larger and more intricate projects.
<P>Volume three, <EM>Beyond Programming,</EM> is still a kind of
sampler of a university computer science curriculum. Each chapter is
an introduction to a topic that you might study in more depth during a
semester at college, if you go on to study computer science. Some of
the topics, like artificial intelligence, are about programming
methods for particular applications. Others, like automata theory,
aren't how-to topics at all but provide a mathematical approach to
understanding what programming is all about. I haven't changed the
table of contents, but most of the chapters have been drastically
rewritten to improve both the technical content and the style of
presentation.
<P>The third reason for a second edition of these books is that the specific
implementations of Logo that I used in 1984 are all obsolete. (One of them,
IBM Logo, is still available if you try very hard, but it's ridiculously
expensive and most IBM sales offices seem to deny that it exists.) The
commercial Logo developers have moved toward products in which Logo is
embedded in some point-and-click graphical application program, with more
emphasis on shapes and colors, and less emphasis on programming itself.
That's probably a good decision for their purposes, but not for mine.
That's why this new edition is based on Berkeley Logo, a free implementation
that I developed along with some of my students. Berkeley Logo is available
for Unix systems, DOS and Windows machines, and Macintosh, and the language is exactly
the same on all platforms. That means I don't have to clutter the text with
footnotes like "If you're using this kind of computer, type that instead."
<P><H2>Why Logo?</H2>
<P>Logo has been the victim of its own success in the elementary
schools. It has acquired a reputation as a trivial language for
babies. Why, then, do I use it as the basis for a series of books
about serious computer science? Why not Pascal or C++ instead?
<P>The truth is that Logo is one of the most powerful programming
language available for home computers. (In 1984 I said "by far the most
powerful," but now home computers have become larger and Logo finally
has some competition.) It is a dialect of Lisp, the
language used in the most advanced research projects in computer
science, and especially in artificial intelligence. Until recently,
all of the <EM>books</EM> about Logo have been pretty trivial, and they
tend to underscore the point by strewing cute pictures of turtles
around. But the cute pictures aren't the whole picture.
<P>What does it mean for a language to be powerful? It <EM>doesn't</EM>
mean that you can write programs in a particular language that do things you
can't do in some other language. (In that sense, all languages are the
same; if you can write a program in Logo, you can write it in Pascal
or BASIC too, one way or another. And vice versa.) Instead, the power
of a language is a way of measuring how much the language helps you
concentrate on the actual problem you wanted to solve in the first
place, rather than having to worry about the constraints of the language.
<P>For example, in C, Pascal, Java, and all of the other languages derived
originally from Fortran, the programmer has to be very explicit about
what goes where in the computer's memory. If you want to group 20
numbers together as a unit, you must "declare an array," saying in
advance that there will be exactly 20 numbers in it. If you change
your mind later and want 21 numbers, too bad. You also have to say
in advance that this array will contain 20 integers, or perhaps 20
numbers with fractions allowed, or perhaps 20 characters of text--but
not some of each. In Logo the entire process of storage allocation
is <EM>automatic;</EM> if your program produces a list of 20 numbers,
the space for that list is provided with no effort by you. If, later,
you want to add a 21st number, that's automatic also.
<P>Another example is the <EM>syntax</EM> of a language, the rules for
constructing legal instructions. All the Fortran-derived languages
have a dozen or so types of instructions, each with its own peculiar
syntax. For example, the BASIC <CODE>PRINT</CODE> statement requires a list
of expressions you want printed. If you separate expressions with
commas, it means to print them one way; if you separate them with
semicolons, that means something else. But you aren't allowed to use
semicolons in other kinds of statements that also require lists of
expressions. In Logo there is only one syntax, the one that invokes
a procedure.
<P>It's not an accident that Logo is more powerful than Pascal or C++;
nor is it just that Logo's designers were smarter. Fortran was
invented before the mathematical basis of computer programming was
well understood, so its design mostly reflects the capabilities (and
the deficiencies) of the computers that happened to be available
then. The Fortran-based languages still have the same fundamental
design, although some of its worst details have been patched over in
the more recent versions like Java and C++. More powerful languages are
based on some particular mathematical model of computing and use that
model in a consistent way. For example, APL is based on the idea of
matrix manipulation; Prolog is based on predicate calculus,
a form of mathematical logic. Logo, like Lisp,
is based on the idea of composition of functions.
<P>The trouble is that if you're just starting this book, you don't have
the background yet to know what I'm talking about! So for now, please
just take my word for it that I'm not insulting you by asking you to
use a "baby" language. After you finish the book, come back and
read this section again.
<P>A big change since 1984 is that Logo is no longer the only member of the
Lisp family available for home computers. Another dialect, Scheme, has
become popular in education. Scheme has many virtues in its own right, but
its popularity is also due in part to the fact that it's the language used
in the best computer science book ever written: <EM>Structure and
Interpretation of Computer Programs,</EM> by Harold Abelson and Gerald Jay
Sussman with Julie Sussman (MIT Press/McGraw-Hill, 1985). I have a foot in
both camps, since I am co-author, with Matthew Wright, of <EM>Simply
Scheme: Introducing Computer Science</EM> (MIT Press, 1994), which is sort of
a Scheme version of the philosophy of this book.
<P>The main difference between Scheme and Logo is that Scheme is more
consistent in its use of functional programming style. For example, in
Scheme, every procedure is what Logo calls an operation--a procedure that
returns a computed value for use by some other procedure. Instead of
writing a program as a sequence of instructions, as in Logo, the Scheme
programmer writes a single expression whose complexity takes the form of
composition of functions.
<P>The Scheme approach is definitely more powerful and cleaner for writing
advanced projects. Its cost is that the Scheme learner must come to terms
from the beginning with the difficult idea of function as object. Logo is
more of a compromise with the traditional, sequential programming style.
That traditional style is limiting, in the end, but people seem to find it
more natural at first. My guess is that ultimately, Logo programmers who
maintain their interest in computing will want to learn Scheme, but that
there's still a place for Logo as a more informal starting point.
<P><H2>Hardware and Software Requirements</H2>
<P>The programs in this series of books are written using Berkeley Logo, a free
interpreter that is available on diskette from the MIT Press or on the
Internet. (Details are in Appendix A.) Berkeley Logo runs on Unix systems,
DOS and Windows machines, and Macintosh.
<P>Since Berkeley Logo is free, I recommend using it with this book, even if
you have another version of Logo that you use for other purposes. One of
the frustrations I had in writing the first edition was dealing with all the
trivial ways in which different Logo dialects differ. (For example, if you
want to add 2 and 3, can you say <CODE>2+3</CODE>, or do you have to put spaces
around the plus sign? Different dialects answer this question differently.)
Nevertheless, the examples in this first volume should be workable in just
about any Logo dialect with some effort in fixing syntactic differences.
The later volumes in the series, though, depend on advanced features of
Berkeley Logo that are missing from many other dialects.
<P>The Berkeley Logo distribution includes the larger programs from these
books. When a program is available in a file, the filename is shown at
the beginning of the chapter. (There are only a few of these in the
first volume, but more in later volumes.)
<P><H2>Words of Wisdom</H2>
<P>The trick in learning to program, as in any intellectual skill, is to
find a balance between theory and practice. This book provides the
theory. One mistake would be to read through it without ever touching
a computer. The other mistake would be to be so eager to get your
hands on the keyboard that you just type in the examples and skip over
the text.
<P>There are no formal exercises at the ends of chapters. That's because
(1) I hate a school-like atmosphere; (2) you're supposed
to be interested enough
already to explore on your own; and (3) I think it's better to
encourage your creativity by letting you invent your own exercises.
However, at appropriate points in the text you'll find questions like
"What do you think would happen if you tried thus-and-such?" and
suggestions for programs you can write. These questions and activities are
indicated by this symbol: ». You'll
get more out of the book if you take these questions seriously.
<P>If you're not part of a formal class, consider working with a friend.
Not only will you keep each other from handwaving too much but it's
more fun.
<P>
<P><A HREF="../v1-toc2.html">(back to Table of Contents)</A>
<P>[no back]
chapter thread <A HREF="ack.html"><STRONG>NEXT</STRONG></A>
<P>
<ADDRESS>
<A HREF="../index.html">Brian Harvey</A>,
<CODE>bh@cs.berkeley.edu</CODE>
</ADDRESS>
</BODY>
</HTML>