about summary refs log tree commit diff stats
path: root/js/games/nluqo.github.io/~bh/ssch26/preview.html
diff options
context:
space:
mode:
Diffstat (limited to 'js/games/nluqo.github.io/~bh/ssch26/preview.html')
-rw-r--r--js/games/nluqo.github.io/~bh/ssch26/preview.html262
1 files changed, 262 insertions, 0 deletions
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
+&quot;real world&quot; programming&mdash;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 &quot;smart&quot; 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
+&quot;structure&quot; part: how a program is organized to reflect the algorithm it
+implements.  The &quot;interpretation&quot; half of the book explains how a
+programming language like Scheme really works&mdash;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 &quot;primitive&quot; 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">&bull;<TD>&nbsp;&nbsp;&nbsp;&nbsp;<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">&bull;<TD>&nbsp;&nbsp;&nbsp;&nbsp;<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">&bull;<TD>&nbsp;&nbsp;&nbsp;&nbsp;<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>&quot;007&quot;</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>