Structure and Interpretation of Computer Programs - 2nd Edition (MIT Electrical Engineering and Computer Science) this question feed

asked by nexus on November 26, 2006 6:58 AM
Abelson and Sussman's classic Structure and Interpretation of Computer Programs teaches readers how to program by employing the tools of abstraction and modularity. The authors' central philosophy is that programming is the task of breaking large problems into small ones. The book spends a great deal of time considering both this decomposition and the process of knitting the smaller pieces back together.

The authors employ this philosophy in their writing technique. The text asks the broad question "What is programming?" Having come to the conclusion that programming consists of procedures and data, the authors set off to explore the related questions of "What is data?" and "What is a procedure?"

The authors build up the simple notion of a procedure to dizzying complexity. The discussion culminates in the description of the code behind the programming language Scheme. The authors finish with examples of how to implement some of the book's concepts on a register machine. Through this journey, the reader not only learns how to program, but also how to think about programming.


Reviews

Thumb_up
Thumb_down

0%
0%
This book trains your mind to do meta-circular interpreters and higher order functions, recursion, and other things schemers take for granted. hey you with thoes 1 * reviews your just a bunch of blubbers
reviewed by jbritt on November 26, 2006 2:02 PM

Thumb_up
Thumb_down

0%
0%
Excellent book to teach computer programming, especially if you are willing to use Scheme.
reviewed by madfool on November 29, 2006 12:11 AM

Thumb_up
Thumb_down

0%
0%
A truly wonderful book. What else can I say?

I discovered it about 10 years into my career in software, on a recommendation from a friend from MIT where it is used for the introductory CompSci course (6.001). Originally, I didn't think a book used in a first course of computer science can contain anything I didn't know already. In the end, I ended up getting Scheme (the LISP variant used for exercises in the book) and spent almost two months working through the exercises in the book. Why? Because it challenged and changed the way I think about software.

Over the years, my thinking was influenced by Wirth's Pascal (abstract data types), later by the C/C++/Java people (K&R, Stroustrup,Gosling) and the OO people (GoF). But Abelson and Sussman presented a richer and more powerful approach - software systems as layers of languages and linguistic abstractions, with linguistic abstractions serving primarily as means of formulating and exploring problems and, only then, as means of specifying algorithms for computers to execute. They get that point across by providing reasonably challenging exercises in LISP using first functional programming (the lambda is fun!!), then data abstractions and generic programming (you end up writing a symbolic algebra program), followed by objects and state (the delayed stream approach is really nice). At this point you are about half way through the book but the really interesting stuff is ahead: first modifying the LISP evaluator to implement lazy evaluation and non-deterministic computing, and finally, implementing the evaluator on register machines.

While working my way through the book, I went through the MIT 6.001 course materials on the MIT OCW website, as well as the Berkeley SICP course which are both based on this book. Both courses are, no doubt, excellent, but in the end I found the best approach for me was to simply stick with the Abelson and Sussman and do the exercises.

reviewed by goonball on November 29, 2006 6:27 AM

Thumb_up
Thumb_down

0%
0%
-- for someone who never has to deal with industrial software. But there is greatness here, so let's start with that.

The book is entirely based on a Lisp dialect. That gives a very strong mathematical note to the whole text, where functions of functions arise early on. This book lays out an aggressive first course in programming, introducing valuable topics like lazy evaluation, logic programming, interpreters, and constraint propagation. These, of course, have many applications and even more implications; the base concepts are useful far beyond the case studies presented here. The students of this course also receive vivid demonstrations of the hazards of parallelism, and the merits of stateless functional programming in eliminating change-of-state race conditions.

Sorry, to say, I'm not a functional programmer. I use imperative languages (call them dys-functional if you must). So do 99.9% of all commercial software developers. They're stateful languages, and reflect the fact that the world has state. It may be elegant to move back and forth along the static, four-dimensional space-time trajectory of moving objects with respect to fixed ones. In practice, however, a car ramming a wall should not be considered a reversible event.

One must also note that the early versions of this book date to the 1980s, before object orientation became widespread. Even the later edition (1996) ignores the basics of OO practice, since they couldn't be captured in the version of Lisp favored here. Instead, examples (ex. p.189) propagate the pernicious practice of hand-coding polymorphism via switch statements or manual table management. I'm not an OO absolutist by any means. I'm painfully aware of its limits, and willing to recommend functional style when it solves specific problems. I am fully cognizant of the iron and silicon that lie under my program, however, and of the mutualism between hardware and software. In all the years I've been building software and hardware, I've never seen a "functional" computer. Sooner or later, all of them store bits - if nothing else, the functional program itself.

There's a lot of good in this book, including a great example of how to design a programming course for a brilliant novice. Believe me, the smart students can be harder to handle than the plodders (but worth it). This may outstrip the plodders, though. And, in the end, it teaches only Lisp - a language with negligible presence in the working world.

//wiredweird
reviewed by teacher on November 29, 2006 6:12 PM

Thumb_up
Thumb_down

0%
0%
whats this programming thing all about? thats what I thought mid-way through a business major in college. so i grabbed this book, because I'm a snob and I thought MIT, comp sci book, this should be a good, definitive introduction.

i read parts of the first chapter. and found myself fascinated. i got sidetracked, finished my finance degree, dabbled in some comp sci classes and c++ books.

Then I returned, mature enough to read the complete book. It was amazing, inspiring. a whirlwind tour of interesting ideas in computer science. it taught me what a program was capable of. I was so inspired, i set out to become a programmer and took some more computer science classes. Start work as a programmer. but if i had never read SICP, and just learned from my classes and co-workers, computer science and programming would be a drudgerous, pointless task to be outsourced to offshore developers.

instead, despite the tedium of having to support poorly designed applications integrated with poorly designed third party software, reading stacks of technical documentation, i continue to be inspired by sicp. it teaches me that there are so many ideas to be explored. that the computer and the software it runs isn't just a filing cabinet or a business process automator. its way to explore problems and think about them. cooperatively with users and designers.

chapter 3 and 4 i keep find myself revisiting. i often find myself thinking about them, grasping them a little deeper each time. i still have some ways to go in be able to actual apply the ideas from the discussion of streams vs mutable objects at teh end of ch 3. i wish i could spend my whole career applying the ideas from the event propagation system, the constraint network, the non-deterministic solver, and the relational programming to different problem domains. i'll try, but you also run into limits with users. users can understand and conceptualize filing cabinets / data entry systems. they have problems when you start talking about more abstract systems.

i like the conscious decision to not waste time talking about class hierarchies. i love the idea of beign treated like a designer, and being walked through so many different aspects of how things work with prototypes. its almost spoiled me. whenever i see a new system now, i often find myself asking - walk me through how this thing works from the inside out. closed source systems annoy me because of SICP.

thank you for writing this inspirational book!
reviewed by bookworks on November 29, 2006 6:25 PM

search

 
 

browse

book tags