diff options
Diffstat (limited to 'js/games/nluqo.github.io/~bh/ssch26')
| -rw-r--r-- | js/games/nluqo.github.io/~bh/ssch26/part7.html | 60 | ||||
| -rw-r--r-- | js/games/nluqo.github.io/~bh/ssch26/preview | 231 | ||||
| -rw-r--r-- | js/games/nluqo.github.io/~bh/ssch26/preview.html | 262 |
3 files changed, 553 insertions, 0 deletions
diff --git a/js/games/nluqo.github.io/~bh/ssch26/part7.html b/js/games/nluqo.github.io/~bh/ssch26/part7.html new file mode 100644 index 0000000..0b0fe31 --- /dev/null +++ b/js/games/nluqo.github.io/~bh/ssch26/part7.html @@ -0,0 +1,60 @@ +<P> + +<P> +<HTML> +<HEAD> +<TITLE>Simply Scheme: Introducing Computer Science, Part 26: Conclusion: Computer Science</TITLE> +</HEAD> +<BODY> +<CITE>Simply Scheme:</CITE> +<CITE>Introducing Computer Science</CITE> 2/e Copyright (C) 1999 MIT +<H2>Part VII</H2> +<H1>Conclusion: Computer Science</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/ssch26.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="../ssch25/database.html"><STRONG>BACK</STRONG></A> +chapter thread <A HREF="preview.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><BIG> + +<P>This is the end of the technical material in this book. We've +explored the big ideas of composition of functions, functions as data, +recursion, abstraction, and sequential programming. As a review, you might +enjoy rereading Chapter 1 to see how the formerly mysterious +examples now make sense. + +<P>This book is intended both as a standalone programming course for people +whose main interest is in something else and as preparation for those who +intend to continue studying computer science. The final chapter is directed +mainly at the latter group, to tell them what to expect. We confess, +though, to the hope that some of the former may have enjoyed this experience +enough to be lured into further study. If you're in that category, you'll +be particularly interested in a preview of coming attractions. + +<P> + +</BIG> +<HR> +<P><A HREF="../ss-toc2.html">(back to Table of Contents)</A><P> +<A HREF="../ssch25/database.html"><STRONG>BACK</STRONG></A> +chapter thread <A HREF="preview.html"><STRONG>NEXT</STRONG></A> + +<P> +<ADDRESS> +<A HREF="../index.html">Brian Harvey</A>, +<CODE>bh@cs.berkeley.edu</CODE> +</ADDRESS> +</BODY> +</HTML> 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 diff --git a/js/games/nluqo.github.io/~bh/ssch26/preview.html b/js/games/nluqo.github.io/~bh/ssch26/preview.html new file mode 100644 index 0000000..7815d18 --- /dev/null +++ b/js/games/nluqo.github.io/~bh/ssch26/preview.html @@ -0,0 +1,262 @@ +<P> + +<P><P><CENTER><IMG SRC="../ss-pics/sicp.jpg" ALT="figure: sicp"></CENTER> +<HTML> +<HEAD> +<TITLE>Simply Scheme: Introducing Computer Science ch 26: What's Next?</TITLE> +</HEAD> +<BODY> +<HR> +<CITE>Simply Scheme:</CITE> +<CITE>Introducing Computer Science</CITE> 2/e Copyright (C) 1999 MIT +<H2>Chapter 26</H2> +<H1>What's Next?</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/ssch26.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="part7.html"><STRONG>BACK</STRONG></A> +chapter thread <A HREF="../ssch27/appendix-running.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>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. + +<P>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? + +<P><H2>The Best Computer Science Book</H2> + +<P>The next step is to read <A NAME="g1"></A><EM>Structure and Interpretation of Computer +Programs</EM> by <A NAME="g2"></A>Harold Abelson and <A NAME="g3"></A>Gerald Jay Sussman +with <A NAME="g4"></A>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 <EM>SICP,</EM> take it! If not, read the +book on your own. + +<P>The big organizing idea of <EM>SICP</EM> is abstraction. We've used +this idea in several ways. We've talked about <EM>data abstraction</EM> 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. + +<P>What we've done in this book covers most of the main ideas in about the first +hundred pages of <EM>SICP.</EM> 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. + +<P>Because there <EM>is</EM> some overlap between what we teach and what they +teach, you may think at first that you can breeze through a course based on +<EM>SICP.</EM> 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 <EM>all</EM> be new to you. + +<P>The core ideas of this book are in the first chapter of <EM>SICP:</EM> +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 <EM>sentence</EM> and <EM>tree</EM> abstract data types. In <EM>SICP</EM> you first learn that lists +themselves are built of an even more fundamental type, the <EM>pairs</EM> +that we mentioned in a pitfall in Chapter 17. 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, <EM>SICP</EM> 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 <CODE>functions</CODE> program. + +<P>The third chapter of <EM>SICP</EM> is largely about non-functional +programming, a topic we only begin in this book. Specifically, <EM>SICP</EM> 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 <EM>objects</EM> 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.) + +<P>You may have forgotten by now that <EM>SICP</EM> stands for <EM>Structure +and Interpretation of Computer Programs.</EM> 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 <CODE>compute</CODE> procedure that evaluates +arithmetic expression trees in Chapter 18 and the <CODE>ss-eval</CODE> +procedure in our spreadsheet program give a hint of what the <EM>SICP</EM> +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. + +<P><H2>Beyond <EM>SICP</EM></H2> + +<P>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. <EM>SICP</EM> 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. + +<P>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).<A NAME="text1" HREF="preview.html#ft1">[1]</A> 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. + +<P>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.) + +<P>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 <EM>halting problem</EM> of +determining in finite time whether some other program would run forever. +<EM>Automata theory</EM> is the study of simplified pseudo-computers to prove +theorems about the capabilities of computers in general. + +<P>A few topics don't fit readily into one of our three groups, such as <EM>numerical analysis,</EM> 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. <EM>Robotics</EM> +involves artificial intelligence programming techniques along with +electrical and mechanical engineering. + +<P><H2>Standard Scheme</H2> + +<P> + +<P>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 <CODE>simply.scm</CODE>, which is listed in +Appendix C. + +<P>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: + +<P><P><TABLE><TR><TH align="right" valign="top">•<TD> <TD valign="top">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 (<CODE>map</CODE> and <CODE>for-each</CODE> are the only standard +ones), and not using <CODE>read-line</CODE>, <CODE>read-string</CODE>, <CODE>show</CODE>, <CODE>show-line</CODE>, <CODE>align</CODE>, or <CODE>close-all-ports</CODE>. Also, you may find it +necessary to use data types we haven't fully explained: characters, +strings, and pairs. +</TABLE><TABLE><TR><TH align="right" valign="top">•<TD> <TD valign="top">Load our <CODE>simply.scm</CODE> 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. +</TABLE><TABLE><TR><TH align="right" valign="top">•<TD> <TD valign="top">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. + +</TABLE> + +<P>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 <CODE>butfirst</CODE> will be just what you need for some project. + +<P>You may be curious about the <EM>implementation</EM> of our tool procedures. +You've already seen some of them, such as the higher-order procedures whose +implementation is described in Chapter 19. The input/output procedures +(<CODE>show</CODE> 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 <CODE>word</CODE>, +<CODE>first</CODE>, and so on, but we also had to rewrite all of the arithmetic +procedures so they work on words like <CODE>"007"</CODE> as well as ordinary numbers. + +<P>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 <EM>Revised<SUP><SMALL>5</SMALL></SUP> Report on the Algorithmic Language Scheme.</EM> 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, <EM>IEEE Standard for the Scheme Programming +Language,</EM> published by the Institute of Electrical and Electronic +Engineers in 1991. Appendix A tells you how to find both documents. + +<P><H2>Last Words</H2> + +<P>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. + +<P>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. + +<P>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. +<A NAME="g5"></A> +<A NAME="g6"></A> + +<P> + +<HR> +<A NAME="ft1" HREF="preview.html#text1">[1]</A> 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.<P> +<P><A HREF="../ss-toc2.html">(back to Table of Contents)</A><P> +<A HREF="part7.html"><STRONG>BACK</STRONG></A> +chapter thread <A HREF="../ssch27/appendix-running.html"><STRONG>NEXT</STRONG></A> + +<P> +<ADDRESS> +<A HREF="../index.html">Brian Harvey</A>, +<CODE>bh@cs.berkeley.edu</CODE> +</ADDRESS> +</BODY> +</HTML> |