1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
|
<P>
<P>
<HTML>
<HEAD>
<TITLE>Simply Scheme:Preface</TITLE>
</HEAD>
<BODY>
<CITE>Simply Scheme</CITE>:
<CITE>Introducing Computer Science</CITE> 2/e Copyright (C) 1999 MIT
<H1>Preface</H1>
<TABLE width="100%"><TR><TD>
<IMG SRC="../simply.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"><CITE><A HREF="http://ccrma.stanford.edu/~matt">Matthew
Wright</A><BR>University of California, Santa Barbara</CITE>
<TR><TD align="right"><BR>
<TR><TD align="right"><A HREF="../pdf/ssch00.pdf">Download PDF version</A>
<TR><TD align="right"><A HREF="../ss-toc2.html">Back to Table of Contents</A>
<TR><TD align="right"><A HREF="foreword.html"><STRONG>BACK</STRONG></A>
chapter thread <A HREF="instructor.html"><STRONG>NEXT</STRONG></A>
<TR><TD align="right"><A HREF="http://mitpress.mit.edu/0262082810">MIT
Press web page for <CITE>Simply Scheme</CITE></A>
</TABLE></TABLE>
<HR>
<P>There are two schools of thought about teaching computer science. We might
caricature the two views this way:
<P><P>
<TABLE><TR><TH align="right" valign="top">•<TD> <TD valign="top"><STRONG>The conservative view:</STRONG> Computer programs have become too large and
complex to encompass in a human mind. Therefore, the job of computer
science education is to teach people how to discipline their work in such a
way that 500 mediocre programmers can join together and produce a program
that correctly meets its specification.
</TABLE><TABLE><TR><TH align="right" valign="top">•<TD> <TD valign="top"><STRONG>The radical view:</STRONG> Computer programs have become too large and
complex to encompass in a human mind. Therefore, the job of computer
science education is to teach people how to expand their minds so that the
programs <EM>can</EM> fit, by learning to think in a vocabulary of larger,
more powerful, more flexible ideas than the obvious ones. Each unit of
programming thought must have a big payoff in the capabilities of the
program.
</TABLE><P>
<P>Of course nobody would admit to endorsing the first approach as we've
described it. Yet many introductory programming courses seem to spend half
their time on obscure rules of the programming language (semicolons go
<EM>between</EM> the instructions in Pascal, but <EM>after</EM> each
instruction in C) and the other half on stylistic commandments (thou shalt
comment each procedure with its preconditions and postconditions; thou shalt
not use <CODE>goto</CODE>). In an article that was <EM>not</EM> intended as a
caricature, the noted computer scientist Edsger Dijkstra argues that
beginning computer science students <EM>should not be allowed to use
computers,</EM> lest they learn to debug their programs interactively instead of
writing programs that can be proven correct by formal methods before
testing.<A NAME="text1" HREF="preface.html#ft1">[1]</A>
<P>If you are about to be a student in an introductory computer science course,
you may already be an experienced programmer of your home computer, or
instead you may have only a vague idea of what you're getting into. Perhaps
you suspect that programming a computer is like programming a VCR:
entering endless obscure numeric codes. Even if you're already a computer
programmer, you may not yet have a clear idea of what computer <EM>
science</EM> means. In either case, what we want to do in this book is put
our best foot forward—introduce you to some new ideas, get you excited,
rather than mold you into a disciplined soldier of the programming army.
<P>In order to understand the big ideas, though, we'll also have to expend some
effort on technical details; studying computer science without writing
computer programs is like trying to study German grammar without learning
any of the words in the language. But we'll try to keep the ideas in view
while struggling with the details, and we hope you'll remember them too.
<P><H2>One Big Idea: Symbolic Programming</H2>
<P>We said that our approach to teaching computer science emphasizes big
ideas. Our explanation of symbolic programming in the following
paragraphs is in part just an illustration of that approach. But we chose
this particular example for another reason also. Scheme, the programming
language used in this book, is an unusual choice for an introductory
computer science course. You may wonder why we didn't use a more
traditional language, such as Pascal, Modula-2, or C. Our discussion of
symbolic programming is the beginning of an answer to that question.
<P>Originally computers were about numbers. Scientists used them to solve
equations; businesses used them to compute the payroll and the inventory.
We were rescued from this boring state of affairs mainly by researchers in
<EM>artificial intelligence—</EM>people who wanted to get
computers to think more nearly the way people do, about ideas in general
rather than just numbers.
<P>What does it mean to represent <EM>ideas</EM> in a computer? Here's a simple
example: We want to teach the computer to answer the question, "Was
so-and-so a Beatle?" We can't quite ask the question in English; in this
book we interact with the computer using Scheme. Our interactions will look
like this:
<P><P>
You type: <CODE>(beatle? 'paul)</CODE>
<P>Computer replies: <CODE>#t</CODE> (computerese for "true")
<P>
<P>You type: <CODE>(beatle? 'elvis)</CODE>
<P>Computer replies: <CODE>#f</CODE> ("false")
<P>
<P>
<P>Here's the program that does the job:
<P><PRE>(define (beatle? person)
(member? person '(john paul george ringo)))
</PRE>
<P>If you examine this program with a (metaphoric) magnifying glass,
you'll find that it's really still full of numbers. In fact, each letter or
punctuation character is represented in the computer by its own unique
number.<A NAME="text2" HREF="preface.html#ft2">[2]</A>But the point
of the example is that you don't have to know that! When you see
<P><PRE>(john paul george ringo)
</PRE>
<P>you don't have to worry about the numbers that represent the
letters inside the computer; all you have to know is that you're seeing a
<EM>sentence</EM> made up of four <EM>words.</EM> Our programming
language hides the underlying mechanism and lets us think in terms more
appropriate to the problem we're trying to solve. That hiding of details is
called <EM>abstraction,</EM> one of the big ideas in this book.
<P>
<P>Programming with words and sentences is an example of
symbolic programming. In 1960 John McCarthy invented the
Lisp programming language to handle symbolic computations like this
one. Our programming language, Scheme, is a modern dialect of Lisp.
<P><H2>Lisp and Radical Computer Science</H2>
<P>Symbolic programming is one aspect of the reason why we like to teach
computer science using Scheme instead of a more traditional language. More
generally, Lisp (and therefore Scheme) was designed to support what we've
called the radical view of computer science. In this view, computer science
is about tools for expressing ideas. Symbolic programming allows <EM>the
computer</EM> to express ideas; other aspects of Lisp's design help <EM>the
programmer</EM> express ideas conveniently. Sometimes that goal
comes in conflict with the conservative computer scientist's goal of
protection against errors.
<P>Here's an example. We want to tell our computer, "To square a number,
multiply it by itself." In Scheme we can say
<P><PRE>(define (square num)
(* num num))
</PRE>
<P>The asterisk represents multiplication, and is followed by the
two operands—in this case, both the same number. This short program works
for any number, of course, as we can see in the following dialogue. (The
lines with <CODE>></CODE> in front are the ones you type.)
<P><PRE>> (square 4)
16
> (square 3.14)
9.8596
> (square -0.3)
0.09
</PRE>
<P>But the proponents of the 500-mediocre-programmer
school<A NAME="text3" HREF="preface.html#ft3">[3]</A> think this straightforward approach
is sinful. "What!" they cry. "You haven't said whether <CODE>num</CODE>
is a whole number or a number with a decimal fraction!" They're
afraid that you might write the <CODE>square</CODE> program with whole
numbers in mind, and then apply it to a decimal fraction <EM>by
mistake.</EM> If you're on a team with 499 other programmers, it's easy
to have failures of communication so that one programmer uses
another's program in unintended ways.
<P>To avoid that danger, they want you to write these two separate programs:
<P><PRE>function SquareOfWholeNumber(num: integer): integer;
begin
SquareOfWholeNumber := num * num
end;
function SquareOfDecimalNumber(num: real): real;
begin
SquareOfDecimalNumber := num * num
end;
</PRE>
<P>Isn't this silly? Why do they pick this particular distinction
(whole numbers and decimals) to worry about? Why not positive and negative
numbers, for example? Why not odd and even numbers?
<P>That two-separate-program example is written in the Pascal language.
Pascal was designed by Niklaus Wirth, one of the leaders of the
structured programming school, specifically to <EM>force</EM> programming
students to write programs that fit conservative ideas about programming
style and technique; you can't write a program in Pascal at all unless you
write it in the approved style. Naturally, this language has been very
popular with school teachers.<A NAME="text4" HREF="preface.html#ft4">[4]</A> That's why, as
we write this in 1993, the overwhelming majority of introductory computer
science classes are taught using Pascal, even though no professional
programmer would be caught dead using it.<A NAME="text5" HREF="preface.html#ft5">[5]</A>
<P>
<P>For fourteen years after the introduction of Pascal in 1970, its hegemony in
computer science education was essentially unchallenged. But in 1984, two
professors at the Massachusetts Institute of Technology and a programmer
at Bolt, Beranek and Newman (a commercial research lab) published
the Scheme-based <EM>Structure and Interpretation of Computer Programs</EM>
(Harold Abelson and Gerald Jay Sussman with
Julie Sussman, MIT Press/McGraw-Hill). That ground-breaking text
brought the artificial intelligence approach to a wide audience for the
first time. We (Brian and Matt) have been teaching their course together
for several years. Each time, we learn something new.
<P>The only trouble with <EM>SICP</EM> is that it was written for MIT students,
all of whom love science and are quite comfortable with formal mathematics.
Also, most of the students who use <EM>SICP</EM> at MIT have already learned
to program computers before they begin. As a result, many other schools
have found the book too challenging for a beginning course. We believe that
everyone who is seriously interested in computer science must read <EM>
SICP</EM> eventually. Our book is a <EM>prequel;</EM> it's meant to teach you
what you need to know in order to read that book
successfully.<A NAME="text6" HREF="preface.html#ft6">[6]</A> Generally
speaking, our primary goal in Parts I-V has been preparation for <EM>
SICP,</EM> while the focus of Part VI is to connect the course with the kinds
of programming used in "real world" application programs like spreadsheets
and databases. (These are the last example and the last project in the
book.)
<P><H2>Who Should Read This Book</H2>
<P>This book is intended as an introduction to computer programming and to
computer science for two kinds of students.
<P>For those whose main interest is in some other field, we provide a
self-contained, one-semester experience with computer programming in a
language with a minimum of complicated notation, so that students can
quickly come in contact with high-level ideas about algorithms, functions,
and recursion. The book ends with the implementation of a spreadsheet
program and a database program, so it complements a computer application
course in which the commercial versions of such programs are used.
<P>For those who intend to continue the study of computer science but who have
no prior programming experience, we offer a preparatory course, less intense
than a traditional CS 1 but not limited to programming technique; we give
the flavor of computer science ideas that will be studied in more depth later
in the curriculum. We also include an extensive discussion of recursion,
which is a stumbling block for many beginning students.
<P>The course at Berkeley for which we wrote this book includes both categories
of students. About 90% of the first-year students who intend to major in
computer science have already had a programming course in high school, and
most of them begin with <EM>SICP.</EM> The other 10% are advised to take
this course first. But many of the students in this course aren't computer
science majors. A few other departments (business administration and
architecture are the main ones) have a specific computer course requirement,
and all students must meet a broader "quantitative reasoning" requirement;
our course satisfies these requirements. Finally, some students come just
out of curiosity about computers.
<P>We assume that you have never programmed a computer. On the other hand, we
do assume that you can <EM>use</EM> a computer; we don't talk about how to
turn it on, how to edit text, and so on, because those details are too
different from one computer model to another. If you've never used a
computer before, you may wish to spend a few days with a book written
specifically for your machine that will introduce you to its operation.
It won't take more than a few days, because you don't have to be an expert
before you read our book. As long as you can start up the Scheme interpreter
and correct your typing mistakes, you're ready.
<P>We assume that you're not a mathematics lover. (If you are, you might be
ready to read <EM>SICP</EM> right away.) The earlier example about squaring
a number is about as advanced as we get. And of course you don't have to do
any arithmetic at all; computers are good at that. You'll learn how to <EM>
tell</EM> the computer to do arithmetic, but that's no harder than using a
pocket calculator. Most of our programming examples are concerned with
words and sentences rather than with numbers. A typical example is to get
Scheme to figure out the plural form of a noun. Usually that means putting
an "s" on the end, but not quite always. (What's the plural of "French
fry"?)
<P><H2>How to Read This Book</H2>
<P>Do the exercises! Whenever we teach programming, we always get students who
say, "When I read the book it all makes sense, but on the exams, when you
ask me to write a program, I never know where to start." Computer science
is two things: a bunch of big ideas, as we've been saying, and also a
skill. You can't learn the skill by watching.
<P>Do the exercises on a computer! It's not good enough to solve the exercises
on paper, even if you feel sure your solution is correct. Maybe it's 99%
correct but there's some little detail you've overlooked. When you run such
a program, you won't get 99% of the answer you wanted. By trying the
exercise on the computer, you get unambiguous feedback. If your program is
correct, you get the response you expected. If not, not.
<P>Don't feel bad if you don't get things right the first time. Even the most
experienced programmers have to <EM>debug</EM> their programs—that is, fix
the parts that don't work. In fact, an important part of what you'll learn
from the exercises is the <EM>process</EM> of debugging your
solutions. It would be too bad if all of your programs in this course
worked the first time, because that would let you avoid the practice in
debugging that you'll certainly need when you write more complicated
programs later. Also, don't be afraid or ashamed to ask for help if you get
stuck. That, too, is part of the working style of professional programmers.
<P>In some of the chapters, we've divided the exercises into two categories,
"boring" and "real." The boring exercises ask you to work through
examples mechanically, to make sure you understand the rules. The
real exercises ask you to <EM>invent</EM> something, usually a small
computer program, but sometimes an explanation of some situation that we
present. (In some chapters, the exercises are just labeled "exercises,"
which means that they're all considered "real.") We don't intend that the
boring exercises be handed in; the idea is for you to do as many of them as
you need to make sure you understand the mechanics of whatever topic you're
learning.
<P>Occasionally we introduce some idea with a simplified explanation, saving
the whole truth for later. We warn you when we do this. Also, we sometimes
write preliminary, partial, or incorrect example programs, and we always
flag these with a comment like
<P><PRE>(define (something foo baz) ;; first version
)
</PRE>
<P>When we introduce technical terms, we sometimes mention the
origin of the word, if it's not obvious, to help prevent the terminology
from seeming arbitrary.
<P>This book starts easy but gets harder, in two different ways. One is that we
spend some time teaching you the basics of Scheme before we get to two
hard big ideas, namely, function as object and recursion. The
earlier chapters are short and simple. You may get the idea that the whole
book will be trivial. You'll change your mind in Parts III and IV.
<P>The other kind of difficulty in the book is that it includes long
programming examples and projects. ("Examples" are programs we write and
describe; "projects" are programs we ask you to write.) Writing a long
program is quite different from writing a short one. Each small piece may
be easy, but fitting them together and remembering all of them at once is a
challenge. The examples and projects get longer as the book progresses, but
even the first example, tic-tac-toe, is much longer and more complex than
anything that comes before it.
<P>As the text explains more fully later, in this book we use some extensions
to the standard Scheme language—features that we implemented ourselves, as
Scheme programs. If you are using this book in a course, your instructor
will provide our programs for you, and you don't have to worry about it.
But if you're reading the book on your own, you'll need to follow the
instructions in Appendix A.
<P>There are several reference documents at the end of the book. If you
don't understand a technical term in the text, try the Glossary for a
short definition, or the General Index to find the more complete
explanation in the text. If you've forgotten how to use a particular
Scheme primitive procedure, look in the Alphabetical Table
of Scheme Primitives, or in the General Index. If you've
forgotten the name of the relevant primitive, refer to the inside
back cover, where all the primitive procedures are listed by
category. Some of our example programs make reference to procedures
that were defined earlier, either in another example or in an
exercise. If you're reading an example program and it refers to some
procedure that's defined elsewhere, you can find that other procedure
in the Index of Defined Procedures.
<P>
<A NAME="ft1" HREF="preface.html#text1">[1]</A> "On the Cruelty of Really Teaching Computer Science,"
<EM>Communications of the ACM,</EM> vol. 32, no. 12, December, 1989.<P>
<A NAME="ft2" HREF="preface.html#text2">[2]</A> The left parenthesis is 40, for example, and the letter
<CODE>d</CODE> is 100. If it were a capital <CODE>D</CODE> it would be 68.<P>
<A NAME="ft3" HREF="preface.html#text3">[3]</A> Their own names for their approach are <EM>
structured programming</EM> and <EM>
software engineering.</EM><P>
<A NAME="ft4" HREF="preface.html#text4">[4]</A> Of course, <EM>your</EM> teacher isn't
an uptight authoritarian, or you wouldn't be using our book!<P>
<A NAME="ft5" HREF="preface.html#text5">[5]</A> Okay, we're exaggerating.
But even Professor Wirth himself has found Pascal so restrictive that he had
to design more flexible languages—although not flexible enough—called
Modula and Oberon.<P>
<A NAME="ft6" HREF="preface.html#text6">[6]</A> As the ideas pioneered by <EM>SICP</EM> have
spread, we are starting to see other intellectually respectable
introductions to computer science that are meant as alternatives to <EM>
SICP.</EM> In particular, we should acknowledge <EM>Scheme and the Art of
Programming</EM> (George Springer and
Daniel P. Friedman, MIT Press/McGraw-Hill, 1989) as a recognized
classic. We believe our book will serve as preparation for theirs, too.<P>
<P><A HREF="../ss-toc2.html">(back to Table of Contents)</A><P>
<A HREF="foreword.html"><STRONG>BACK</STRONG></A>
chapter thread <A HREF="instructor.html"><STRONG>NEXT</STRONG></A>
<P>
<ADDRESS>
<A HREF="../index.html">Brian Harvey</A>,
<CODE>bh@cs.berkeley.edu</CODE>
</ADDRESS>
</BODY>
</HTML>
|