| 
 | 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