Skip to content

Commit ab36f28

Browse files
Adding back missing file
1 parent c2629ab commit ab36f28

File tree

2 files changed

+221
-1
lines changed

2 files changed

+221
-1
lines changed

javascript/latexContent.js

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -868,7 +868,7 @@ you were first led up to it, that you can make it more.''\\end{minipage}}{\\norm
868868
\\cleardoublepage
869869
\\pagestyle{Preface}
870870
\\input{./others/03prefaces03.tex}
871-
% \\pagestyle{Preface1996}
871+
%% \\pagestyle{Preface1996}
872872
\\input{./others/03prefaces96.tex}
873873
%% \\pagestyle{Preface1984}
874874
%% \\input{./others/03prefaces84.tex}

xml/others/03prefaces96.xml

Lines changed: 220 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,220 @@
1+
<MATTER>
2+
<NAME>
3+
Preface to the Second Edition
4+
</NAME>
5+
<SECTION>
6+
<NAME>
7+
Preface to the Second Edition
8+
</NAME>
9+
<EPIGRAPH>
10+
Is it possible that software is not like anything else, that it
11+
is meant to be discarded: that the whole point is to
12+
always see it as a soap bubble?
13+
<ATTRIBUTION>
14+
<INDEX>Perlis, Alan J.</INDEX>
15+
<AUTHOR>Alan J. Perlis</AUTHOR>
16+
</ATTRIBUTION>
17+
</EPIGRAPH>
18+
19+
<TEXT><PDF_ONLY>\noindent</PDF_ONLY>
20+
The material in this book has been the basis of MIT's entry-level
21+
computer science subject since 1980. We had been teaching this
22+
material for four years when the first edition was published, and
23+
twelve more years have elapsed until the appearance of this second
24+
edition. We are pleased that our work has been widely adopted and
25+
incorporated into other texts. We have seen our students take the
26+
ideas and programs in this book and build them in as the core of new
27+
computer systems and languages. In literal realization of an ancient
28+
Talmudic pun, our students have become our builders. We are lucky to
29+
have such capable students and such accomplished builders.
30+
</TEXT>
31+
<TEXT>
32+
In preparing this edition, we have incorporated hundreds of
33+
clarifications suggested by our own teaching experience and the
34+
comments of colleagues at MIT and elsewhere. We have redesigned
35+
most of the major programming systems in the book, including
36+
the generic-arithmetic system, the interpreters, the register-machine
37+
simulator, and the compiler; and we have rewritten all the program
38+
examples to ensure that any Scheme implementation conforming to
39+
the IEEE Scheme standard (IEEE 1990) will be able to run the code.
40+
</TEXT>
41+
<TEXT>
42+
This edition emphasizes several new themes. The most important
43+
of these is the central role played by different approaches to
44+
dealing with time in computational models: objects with state,
45+
concurrent programming, functional programming, lazy evaluation,
46+
and nondeterministic programming. We have included new sections on
47+
concurrency and nondeterminism, and we have tried to integrate this
48+
theme throughout the book.
49+
</TEXT>
50+
<TEXT>
51+
The first edition of the book closely followed the syllabus of our MIT
52+
one-semester subject. With all the new material in the second
53+
edition, it will not be possible to cover everything in a single
54+
semester, so the instructor will have to pick and choose. In our own
55+
teaching, we sometimes skip the section on logic programming
56+
(section<SPACE/><REF NAME="sec:logic-programming"/>),
57+
we have students use the
58+
register-machine simulator but we do not cover its implementation
59+
(section<SPACE/><REF NAME="sec:simulator"/>),
60+
and we give only a cursory overview of
61+
the compiler
62+
(section<SPACE/><REF NAME="sec:compilation"/>).
63+
Even so, this is still
64+
an intense course. Some instructors may wish to cover only the first
65+
three or four chapters, leaving the other material for subsequent
66+
courses.
67+
</TEXT>
68+
<TEXT>
69+
The World Wide Web site <LINK address="https://mitpress.mit.edu/sites/default/files/sicp/index.html">of MIT Press</LINK>
70+
provides support for users of this book.
71+
This includes programs from the book,
72+
sample programming assignments, supplementary materials,
73+
and downloadable implementations of the Scheme dialect of Lisp.
74+
</TEXT>
75+
76+
<SIGNATURE>
77+
<ATTRIBUTION>
78+
<AUTHOR>Harold Abelson and Gerald Jay Sussman</AUTHOR>
79+
</ATTRIBUTION>
80+
</SIGNATURE>
81+
</SECTION>
82+
83+
<SPLITINLINE>
84+
<JAVASCRIPT>
85+
<PDF_ONLY>\newpage</PDF_ONLY>
86+
<SECTION>
87+
<NAME>Preface to the First Edition</NAME>
88+
</SECTION>
89+
</JAVASCRIPT>
90+
<SCHEME>
91+
<NAME>Preface to the First Edition</NAME>
92+
</SCHEME>
93+
</SPLITINLINE>
94+
95+
<EPIGRAPH>
96+
A computer is like a violin. You can imagine a novice trying first a
97+
phonograph and then a violin. The latter, he says, sounds terrible.
98+
That is the argument we have heard from our humanists and most of our
99+
computer scientists. Computer programs are good, they say, for
100+
particular purposes, but they aren't flexible. Neither is a violin,
101+
or a typewriter, until you learn how to use it.
102+
<ATTRIBUTION>
103+
<AUTHOR>Marvin Minsky</AUTHOR>
104+
<INDEX>Minsky, Marvin Lee</INDEX>
105+
<TITLE><QUOTE>Why Programming Is a Good
106+
Medium for Expressing Poorly-Understood and Sloppily-Formulated
107+
Ideas</QUOTE></TITLE>
108+
</ATTRIBUTION>
109+
</EPIGRAPH>
110+
<TEXT><PDF_ONLY>\noindent</PDF_ONLY>
111+
<QUOTE>The Structure and Interpretation of Computer Programs</QUOTE> is the
112+
entry-level subject in computer science at the Massachusetts Institute
113+
of Technology. It is required of all students at MIT who major
114+
in electrical engineering or in computer science, as one-fourth of the
115+
<QUOTE>common core curriculum,</QUOTE> which also includes two subjects on
116+
circuits and linear systems and a subject on the design of digital
117+
systems. We have been involved in the development of this subject
118+
since 1978, and we have taught this material in its present form since
119+
the fall of 1980 to between 600 and 700 students each year. Most of
120+
these students have had little or no prior formal training in
121+
computation, although many have played with computers a bit and a few
122+
have had extensive programming or hardware-design experience.
123+
</TEXT>
124+
<TEXT>
125+
Our design of this introductory computer-science subject reflects two
126+
major concerns. First, we want to establish the idea that a computer
127+
language is not just a way of getting a computer to perform operations
128+
but rather that it is a novel formal medium for expressing ideas about
129+
methodology. Thus, programs must be written for people to read, and
130+
only incidentally for machines to execute. Second, we believe that
131+
the essential material to be addressed by a subject at this level is
132+
not the syntax of particular programming-language constructs, nor
133+
clever algorithms for computing particular functions efficiently, nor
134+
even the mathematical analysis of algorithms and the foundations of
135+
computing, but rather the techniques used to control the intellectual
136+
complexity of large software systems.
137+
</TEXT>
138+
<TEXT>
139+
Our goal is that students who complete this subject should have a good
140+
feel for the elements of style and the aesthetics of programming.
141+
They should have command of the major techniques for controlling
142+
complexity in a large system. They should be capable of reading a
143+
50-page-long program, if it is written in an exemplary style. They
144+
should know what not to read, and what they need not understand at any
145+
moment. They should feel secure about modifying a program, retaining
146+
the spirit and style of the original author.
147+
</TEXT>
148+
<TEXT>
149+
These skills are by no means unique to computer programming. The
150+
techniques we teach and draw upon are common to all of engineering
151+
design. We control complexity by building abstractions that hide
152+
details when appropriate. We control complexity by establishing
153+
conventional interfaces that enable us to construct systems by
154+
combining standard, well-understood pieces in a <QUOTE>mix and match</QUOTE> way.
155+
We control complexity by establishing new languages for describing a
156+
design, each of which emphasizes particular aspects of the design and
157+
deemphasizes others.
158+
</TEXT>
159+
<TEXT>
160+
Underlying our approach to this subject is our conviction that
161+
<QUOTE>computer science</QUOTE> is not a science and that its significance has
162+
little to do with computers. The computer revolution is a revolution
163+
in the way we think and in the way we express what we think. The
164+
essence of this change is the emergence of what might best be called
165+
<EM>procedural epistemology</EM><EMDASH/>the study of the structure of
166+
knowledge from an imperative point of view, as opposed to the more
167+
declarative point of view taken by classical mathematical subjects.
168+
Mathematics provides a framework for dealing precisely with notions of
169+
<QUOTE>what is.</QUOTE> Computation provides a framework for dealing precisely
170+
with notions of <QUOTE>how to.</QUOTE>
171+
</TEXT>
172+
<TEXT>
173+
In teaching our material we use a dialect of the programming language
174+
Lisp. We never formally teach the language, because we don't have to.
175+
We just use it, and students pick it up in a few days. This is one
176+
great advantage of Lisp-like languages: They have very few ways of
177+
forming compound expressions, and almost no syntactic structure. All
178+
of the formal properties can be covered in an hour, like the rules of
179+
chess. After a short time we forget about syntactic details of the
180+
language (because there are none) and get on with the real
181+
issues<EMDASH/>figuring out what we want to compute, how we will decompose
182+
problems into manageable parts, and how we will work on the parts.
183+
Another advantage of Lisp is that it supports (but does not enforce)
184+
more of the large-scale strategies for modular decomposition of
185+
programs than any other language we know. We can make procedural and
186+
data abstractions, we can use higher-order functions to capture common
187+
patterns of usage, we can model local state using assignment and data
188+
mutation, we can link parts of a program with streams and delayed
189+
evaluation, and we can easily implement embedded languages. All of
190+
this is embedded in an interactive environment with excellent support
191+
for incremental program design, construction, testing, and debugging.
192+
We thank all the generations of Lisp wizards, starting with John
193+
McCarthy, who have fashioned a fine tool of unprecedented power and
194+
elegance.
195+
</TEXT>
196+
<TEXT>
197+
Scheme, the dialect of Lisp that we use, is an attempt to bring
198+
together the power and elegance of Lisp and Algol. From Lisp we take
199+
the metalinguistic power that derives from the simple syntax, the
200+
uniform representation of programs as data objects, and the
201+
garbage-collected heap-allocated data. From Algol we take lexical
202+
scoping and block structure, which are gifts from the pioneers of
203+
programming-language design who were on the Algol committee. We wish
204+
to cite John Reynolds and Peter Landin for their insights into the
205+
relationship of Church's lambda calculus to the structure of
206+
programming languages. We also recognize our debt to the
207+
mathematicians who scouted out this territory decades before computers
208+
appeared on the scene. These pioneers include Alonzo Church, Barkley
209+
Rosser, Stephen Kleene, and Haskell Curry.
210+
</TEXT>
211+
212+
<SIGNATURE>
213+
<ATTRIBUTION>
214+
<AUTHOR>Harold Abelson and Gerald Jay Sussman</AUTHOR>
215+
</ATTRIBUTION>
216+
</SIGNATURE>
217+
218+
219+
</MATTER>
220+

0 commit comments

Comments
 (0)