-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathbook-Z-H-7.html
149 lines (131 loc) · 7.39 KB
/
book-Z-H-7.html
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
<!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<!-- Generated from TeX source by tex2page, v 4n,
(c) Dorai Sitaram, http://www.cs.rice.edu/~dorai/tex2page -->
<head>
<title>
Structure and Interpretation
of Computer Programs
</title>
<link rel="stylesheet" type="text/css" href="book-Z-C.css" title=default>
<meta name=robots content="noindex,follow">
</head>
<body>
<p><div class=navigation>[Go to <a href="book.html">first</a>,
<a href="book-Z-H-6.html">previous</a>,
<a href="book-Z-H-8.html">next</a> page; <a href="book-Z-H-4.html#%_toc_start">contents</a>; <a href="book-Z-H-38.html#%_index_start">index</a>]</div><p>
<a name="%_chap_IGNORE"></a>
<h1 class=chapter>
<div class=chapterheading> </div><p>
<a href="book-Z-H-4.html#%_toc_%_chap_IGNORE">Preface to the First Edition</a></h1><p>
<p>
<div align=right>
<table width=60%><tr><td>
<span class=epigraph>
<p>
A computer is like a violin. You can imagine a novice trying first a
phonograph and then a violin. The latter, he says, sounds terrible.
That is the argument we have heard from our humanists and most of our
computer scientists. Computer programs are good, they say, for
particular purposes, but they aren't flexible. Neither is a violin,
or a typewriter, until you learn how to use it.<p>
<a name="%_idx_4"></a>Marvin Minsky, ``Why Programming Is a Good<br>
Medium for Expressing Poorly-Understood and Sloppily-Formulated
Ideas''<p>
</span>
</td></tr></table>
</div>
<p><p>
``The Structure and Interpretation of Computer Programs'' is the
entry-level subject in computer science at the Massachusetts Institute
of Technology. It is required of all students at MIT who major
in electrical engineering or in computer science, as one-fourth of the
``common core curriculum,'' which also includes two subjects on
circuits and linear systems and a subject on the design of digital
systems. We have been involved in the development of this subject
since 1978, and we have taught this material in its present form since
the fall of 1980 to between 600 and 700 students each year. Most of
these students have had little or no prior formal training in
computation, although many have played with computers a bit and a few
have had extensive programming or hardware-design experience.<p>
Our design of this introductory computer-science subject reflects two
major concerns. First, we want to establish the idea that a computer
language is not just a way of getting a computer to perform operations
but rather that it is a novel formal medium for expressing ideas about
methodology. Thus, programs must be written for people to read, and
only incidentally for machines to execute. Second, we believe that
the essential material to be addressed by a subject at this level is
not the syntax of particular programming-language constructs, nor
clever algorithms for computing particular functions efficiently, nor
even the mathematical analysis of algorithms and the foundations of
computing, but rather the techniques used to control the intellectual
complexity of large software systems.<p>
Our goal is that students who complete this subject should have a good
feel for the elements of style and the aesthetics of programming.
They should have command of the major techniques for controlling
complexity in a large system. They should be capable of reading a
50-page-long program, if it is written in an exemplary style. They
should know what not to read, and what they need not understand at any
moment. They should feel secure about modifying a program, retaining
the spirit and style of the original author.<p>
These skills are by no means unique to computer programming. The
techniques we teach and draw upon are common to all of engineering
design. We control complexity by building abstractions that hide
details when appropriate. We control complexity by establishing
conventional interfaces that enable us to construct systems by
combining standard, well-understood pieces in a ``mix and match'' way.
We control complexity by establishing new languages for describing a
design, each of which emphasizes particular aspects of the design and
deemphasizes others.<p>
Underlying our approach to this subject is our conviction that
``computer science'' is not a science and that its significance has
little to do with computers. The computer revolution is a revolution
in the way we think and in the way we express what we think. The
essence of this change is the emergence of what might best be called
<em>procedural epistemology</em> -- the study of the structure of
knowledge from an imperative point of view, as opposed to the more
declarative point of view taken by classical mathematical subjects.
Mathematics provides a framework for dealing precisely with notions of
``what is.'' Computation provides a framework for dealing precisely
with notions of ``how to.''<p>
In teaching our material we use a dialect of the programming language
Lisp. We never formally teach the language, because we don't have to.
We just use it, and students pick it up in a few days. This is one
great advantage of Lisp-like languages: They have very few ways of
forming compound expressions, and almost no syntactic structure. All
of the formal properties can be covered in an hour, like the rules of
chess. After a short time we forget about syntactic details of the
language (because there are none) and get on with the real
issues -- figuring out what we want to compute, how we will decompose
problems into manageable parts, and how we will work on the parts.
Another advantage of Lisp is that it supports (but does not enforce)
more of the large-scale strategies for modular decomposition of
programs than any other language we know. We can make procedural and
data abstractions, we can use higher-order functions to capture common
patterns of usage, we can model local state using assignment and data
mutation, we can link parts of a program with streams and delayed
evaluation, and we can easily implement embedded languages. All of
this is embedded in an interactive environment with excellent support
for incremental program design, construction, testing, and debugging.
We thank all the generations of Lisp wizards, starting with John
McCarthy, who have fashioned a fine tool of unprecedented power and
elegance.<p>
Scheme, the dialect of Lisp that we use, is an attempt to bring
together the power and elegance of Lisp and Algol. From Lisp we take
the metalinguistic power that derives from the simple syntax, the
uniform representation of programs as data objects, and the
garbage-collected heap-allocated data. From Algol we take lexical
scoping and block structure, which are gifts from the pioneers of
programming-language design who were on the Algol committee. We wish
to cite John Reynolds and Peter Landin for their insights into the
relationship of Church's lambda calculus to the structure of
programming languages. We also recognize our debt to the
mathematicians who scouted out this territory decades before computers
appeared on the scene. These pioneers include Alonzo Church, Barkley
Rosser, Stephen Kleene, and Haskell Curry.<p>
<p>
<p><div class=navigation>[Go to <a href="book.html">first</a>,
<a href="book-Z-H-6.html">previous</a>,
<a href="book-Z-H-8.html">next</a> page; <a href="book-Z-H-4.html#%_toc_start">contents</a>; <a href="book-Z-H-38.html#%_index_start">index</a>]</div><p>
</body>
</html>