diff options
Diffstat (limited to 'js/games/nluqo.github.io/~bh/ssch26/preview')
| -rw-r--r-- | js/games/nluqo.github.io/~bh/ssch26/preview | 231 |
1 files changed, 231 insertions, 0 deletions
diff --git a/js/games/nluqo.github.io/~bh/ssch26/preview b/js/games/nluqo.github.io/~bh/ssch26/preview new file mode 100644 index 0000000..24e71bc --- /dev/null +++ b/js/games/nluqo.github.io/~bh/ssch26/preview @@ -0,0 +1,231 @@ +\input bkmacs +\bigskip +\photo{}{\pspicture{4in}{sicp}{sicp}{\TrimBoundingBox{40pt}}\vfill} +\chapter{What's Next?} +\chaptag{\preview} + +We've concluded this introduction to computer science with two examples of +``real world'' programming---spreadsheets and databases. What may have +seemed like a pointless game near the beginning of the book allowed us to +write these serious programs. + +But we've only begun to explore the ideas that make up computer science. +If you're interested in learning more, where do you go from here? + +\subhd{The Best Computer Science Book} + +The next step is to read \itidx{Structure and Interpretation of Computer +Programs} by \swapidx{Harold}{Abelson} and \swapidx{Gerald Jay}{Sussman} +with \swapidx{Julie}{Sussman} (MIT Press/McGraw-Hill, Second Edition, +1996). Our book was inspired by theirs, and our main goal in writing this +book has been to prepare you for that one. If you're a student and your +school offers a course based on {\it SICP,\/} take it! If not, read the +book on your own. + +The big organizing idea of {\it SICP\/} is \idx{abstraction}. We've used +this idea in several ways. We've talked about {\it data abstraction\/} such +as inventing the sentence and tree data types. We've also invented more +specialized data types, such as positions in the tic-tac-toe program and +cells in the spreadsheet program. We've discussed how higher-order +procedures abstract a pattern of computation by using an extra argument to +represent the function that's abstracted out. + +What we've done in this book covers most of the main ideas in about the first +hundred pages of {\it SICP.\/} But don't skip over those pages. In the +footnotes alone you'll find ideas about numerical analysis, cryptography, +epistemology (the study of what it means to know something), number theory, +programming language design, and the analysis of algorithms. + +Because there {\it is\/} some overlap between what we teach and what they +teach, you may think at first that you can breeze through a course based on +{\it SICP.\/} Don't fall into that trap; even from the beginning there will +be some ideas that are new to you, and after about four weeks it will {\it +all\/} be new to you. + +The core ideas of this book are in the first chapter of {\it SICP:\/} +functions, recursion, the substitution model, and higher-order functions. +The second chapter is about lists and data abstraction, extending the ladder +of data abstractions in both directions. (That is, in our book, lists are +the fundamental data type used to construct the {\it sentence\/} and {\it +tree\/} abstract data types. In {\it SICP\/} you first learn that lists +themselves are built of an even more fundamental type, the {\it pairs\/} +that we mentioned in a pitfall in Chapter \lists. Then you learn about +several more abstract data types that can be built out of lists.) The idea +of data abstraction extends beyond inventing new types. For example, {\it +SICP\/} uses data structures not only to contain passive information but +also to control the algorithms used in a computation. You got a taste of +this in the a-list of functions in the {\tt functions} program. + +The third chapter of {\it SICP\/} is largely about non-functional +programming, a topic we only begin in this book. Specifically, {\it +SICP\/} introduces object-oriented programming, a very popular technique in +which the dichotomy between ``smart'' procedures and passive data is broken +down. Instead of a single program controlling the computation, there are +many {\it objects\/} that contain both algorithms and data; each object acts +independently of the others. (This is a metaphor; there is still one +computer implementing all this activity. The point is that the programmer +is able to think in terms of the metaphor, and the mechanism that simulates +the independent objects is hidden behind the object abstraction.) + +You may have forgotten by now that {\it SICP\/} stands for {\it Structure +and Interpretation of Computer Programs.\/} We've been talking about the +``structure'' part:\ how a program is organized to reflect the algorithm it +implements. The ``interpretation'' half of the book explains how a +programming language like Scheme really works---how a computer understands +the program and carries out the activities that the program requests. The +centerpiece of the interpretation part of the book is the Scheme interpreter +in the fourth chapter, +a program that takes any other Scheme program as its data and does +what that program specifies. (The {\tt compute} procedure that evaluates +arithmetic expression trees in Chapter \trees\ and the {\tt ss-eval} +procedure in our spreadsheet program give a hint of what the {\it SICP\/} +Scheme evaluator is like.) The book goes on to implement different +programming languages and illustrate a variety of implementation techniques. +Finally, the fifth chapter introduces the study of machine organization:\ how +computer hardware carries out a program. + +\subhd{Beyond {\it SICP\/}} + +Computer science can be broadly divided into three areas:\ software, +hardware, and theory. (Of course not everyone will agree with our division +in detail.) This book is about software. {\it SICP\/} is also mostly about +software, although it introduces some ideas from the other two areas. More +advanced computer science courses will concentrate on one particular area. + +Software includes programming languages, operating systems, and application +programs. You know what a programming language is; there are courses on +language design questions (why one language is different from another) and +implementation (for example, how to write a Scheme +interpreter).\footnt{Many beginners think that studying computer science +means learning a lot of different programming languages. Perhaps you start +with BASIC, then you learn Pascal, then C, and so on. That's not +true. The crucial ideas in computer science can be expressed in any modern +language; it's unusual for a computer science student to be taught more than +two languages throughout college.} An operating system is a program +that maintains disk file structures and allows different programs to run on +a computer without interfering with each other. Application programming +techniques studied in computer science courses include database management, +graphics programming, user interfaces, and artificial intelligence. + +The study of computer hardware ranges from physical principles, through the +workings of electronic components such as transistors, to large-scale +circuits such as memories and adders, to the design of actual computers. This +is a range of levels of abstraction, just as there are levels of abstraction +in programming. At the higher levels of abstraction, you can think of an +electronic circuit as a perfect representation of some function that it +implements; that is, the signals coming out the output wires are functions +of the signals coming in at the input wires. At a lower level of +abstraction, you have to think about the limitations of physical devices. +(For example, a device may fail if its output is attached to the inputs of +too many other devices. It's as if you could use the return value from +a function only a certain number of times.) + +Theoretical computer science is a kind of applied mathematics. It includes +analysis of algorithms, which is the study of how fast one program runs +compared to another. (We touched on this topic when we mentioned that the +simple selection sort is slower than the more complicated mergesort. +Analysis of algorithms provides the tools to show exactly how much slower.) +Theoreticians also study problems that can't be solved by any computer +program at all; the most famous example is the {\it halting problem\/} of +determining in finite time whether some other program would run forever. +{\it Automata theory\/} is the study of simplified pseudo-computers to prove +theorems about the capabilities of computers in general. + +A few topics don't fit readily into one of our three groups, such as {\it +numerical analysis,\/} the study of how computers do arithmetic to ensure +that the algorithms used really give correct results. This field involves +aspects of programming, hardware design, and mathematics. {\it Robotics\/} +involves artificial intelligence programming techniques along with +electrical and mechanical engineering. + +\backskipsubhd{Standard Scheme}{8} + +{\blskip{2} + +As we've mentioned, this book uses a lot of ``primitive'' procedures that +aren't part of standard Scheme. These are procedures we wrote in +Scheme and included in the file {\tt simply.scm}, which is listed in +Appendix C\null. + +When you use Scheme in some other context, it probably won't come with these +procedures included. There are three things you can do about this: + +\medskip +{\parindent=1em +\bb Learn to love standard Scheme. That means not using the word and +sentence functions, not using our implementation of trees, not using our +higher-order procedures ({\tt map} and {\tt for-each} are the only standard +ones), and not using {\tt read-line}, {\tt read-string}, {\tt show}, {\tt +show-line}, {\tt align}, or {\tt close-all-ports}. Also, you may find it +necessary to use data types we haven't fully explained:\ characters, +strings, and pairs. +\bb Load our {\tt simply.scm} and continue to work in the style we've used +in this book. The advantage is that (in our humble opinion) we've provided +some very convenient facilities. The disadvantage is that other Scheme +programmers won't understand your programs unless they've read our book. +\bb Develop your own collection of tools to match the kind of programming +you're doing in the new situations that come up. You can start with some +of ours and add new procedures that you invent. + +} + +Actually, all three of these are good ideas. If you are going to continue +working with Scheme, you'll certainly need to know what's in the standard and +what's an extension to the language. After a while you're bound to develop +a collection of tools that fit with your own preferred programming style. +And sometimes {\tt butfirst} will be just what you need for some project. + +You may be curious about the {\it implementation\/} of our tool procedures. +You've already seen some of them, such as the higher-order procedures whose +implementation is described in Chapter \implhof. The input/output procedures +({\tt show} and its friends) are straightforward once you've learned about +the character data type. But you'll find that the implementation of words +is quite complicated. Not only did we have to write the obvious {\tt word}, +{\tt first}, and so on, but we also had to rewrite all of the arithmetic +procedures so they work on words like {\tt "007"} as well as ordinary numbers. + +There are two documents that specify exactly what makes up standard Scheme. +The first is updated fairly frequently to reflect ongoing experimentation in +the language design. As we go to press, the most recent edition is called +the {\it Revised\/${}^5$ Report on the Algorithmic Language Scheme.\/} The +second document is meant to provide a more stable basis for people who +depend on a language that's guaranteed not to become obsolete; it's IEEE +Standard 1178-1990, {\it IEEE Standard for the Scheme Programming +Language,\/} published by the Institute of Electrical and Electronic +Engineers in 1991. Appendix A tells you how to find both documents. + +\backskipsubhd{Last Words}{8} + +It's hard to wrap up something like this without sounding preachy. Perhaps +you'll forgive us this one section since we've been so cool all +through the rest of the book. + +We thought of two general points that we want to leave you with. First, in +our teaching experience at Berkeley we've seen many students learn the ideas +of functional programming in Scheme, then seem to forget all the ideas when +they use another programming language, such as C. Part of the skill of a +computer scientist is to see past surface differences in notation and +understand, for example, that if the best way to solve some problem in Scheme +is with a recursive procedure, then it's probably the best way in C, too. + +The second point is that it's very easy to get a narrow technical education, +learn lots of great ideas about computer science, and still have a hard time +dealing with the rest of reality. The utilitarian way to put it is that when +you work as a computer programmer it's rare that you can just sit in your +corner and write programs. Instead, you have to cooperate with other people +on a team project; you have to write documentation both for other +programmers and for the people who will eventually use your program; you have +to talk with customers and find out what they really want the program to do, +before you write it. For all these reasons you have to work at developing +communication skills just as much as you work at your programming skills. +But the utilitarian argument is just our sneaky way of convincing +you; the truth is that we want you to know about things that have nothing to +do with your technical work. Matt majored in music along with computer +science; Brian has a degree in clinical psychology. After you read Abelson +and Sussman, go on to read Freud and Marx. +\justidx{Freud, Sigmund} +\justidx{Marx, Karl} + +} % skip kludge + +\bye |