Customer Reviews

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

5 star:		(96)
4 star:		(11)
3 star:		(8)
2 star:		(3)
1 star:		(53)

 

 

I think its fascinating that there is such a split between those who love and hate this book. For most books, the review is a bell-shaped curve of star ratings; this one has a peak at 1, a peak at 5, and very little in between. How could this be? I think it is because SICP is a very personal message that works only if the reader is at heart a computer scientist (or willing to become one). So I agree that the book's odds of success are better if you read it after having some experience.

To use an analogy, if SICP were about automobiles, it would be for the person who wants to know how cars work, how they are built, and how one might design fuel-efficient, safe, reliable vehicles for the 21st century. The people who hate SICP are the ones who just want to know how to drive their car on the highway, just like everyone else.

Those who hate SICP think it doesn't deliver enough tips and tricks for the amount of time it takes to read. But if you're like me, you're not looking for one more trick, rather you're looking for a way of synthesizing what you already know, and building a rich framework onto which you can add new learning over a career. That's what SICP has done for me. I read a draft version of the book around 1982, when I was in grad school, and it changed the way I think about my profession. If you're a thoughtful computer scientist (or want to be one), it will change your life too.

Some of the reviewers complain that SICP doesn't teach the basics of OO design, and so on. In a sense they are right. The book doesn't directly tell you how to design and write an object-oriented program using the subset of object-oriented principles that show up in the syntax of Java or C++. Rather, the book tells you what those principles are, how they came to be selected as worthwhile, how they can be implemented from the ground up, and how a different combination of principles might be more appropriate for some particular problems. This approach requires you to understand the range of possibilities, and to think about trade-offs as you go through the design process. Programming is a craft that is subject to frequent failure: many projects are started and abandoned because the designers do not have the flexibility, experience and understanding to come up with a suitable design and implementation. SICP gives you an approach that will succeed, but it is an approach based on principles and wisdom, not on a checklist. If you don't understand the principles, or if you are the kind of person who wants to be given a cookbook of what to do rather than to think creatively, or if you only want to work on problems that are pretty much like the problem you worked on last time, then this approach will not work for you. There are other approaches that will be more reproducible for a limited range of simple problems, but there is no better way than SICP to learn how to address the truly hard problems.

Donald Knuth says he wrote his books for "the one person in 50 who has this strange way of thinking that makes a programmer". I think the most amazing thing about SICP is that there are so FEW people who hate it: if Knuth were right, then only 1 out of 50 people would be giving this 5 stars, instead of about 25 out of 50. Now, a big part of the explanation is that the audience is self-selected, and is not a representative sample. But I think part of it is because Sussman and Abelson have succeeded grandly in communicating "this strange way of thinking" to (some but not all) people who otherwise would never get there.

This is one of the great classics of computer science. I bought my first copy 15 years ago, and I still don't feel I have learned everything the book has to teach.

I have learned enough to write a couple books on Lisp that (currently) have four to five stars. Yet SICP, which is pretty much the bible of our world, has only three? How can this be?

Reading the reviews made it clear what happened. An optimistic professor somewhere has been feeding SICP to undergrads who are not ready for it. But it is encouraging to see how many thoughtful people have come forward to defend the book.

Let's see if we can put this in terms that the undergrads will understand -- a problem set:

1. Kenneth Clark said that if a lot of smart people have liked something that you don't, you should try and figure out what they saw in it. List 10 qualities that SICP's defenders have claimed for it.

2. How is the intention of SICP different from that of Knuth? Kernighan & Ritchie? An algorithms textbook?

3. Does any other book fulfill this purpose better?

4. What other programming books first published in the mid 1980s are still relevant today?

5. Could the concepts in this book have been presented any better in a language other than Scheme?

6. Who is al? Why is his name in lowercase?

The negative reviewers entirely missed the point of this book. The issues are not c++ versus scheme, nor the gap between the book's examples and real-world programs, nor that recursion is less intuitive than looping.

The real point is to teach some very core foundations of computer science that show up everywhere. For example, supposedly revolutionary XML looks a heck of a lot like a nested scheme list, first described in 1960. And processing an active server page (or Java server page) is very much like the textbook's specialized language evaluator. Finally, c++ polymorphism through vtables and part of Microsoft's COM mechanics are the exact same thing as the book's data-directed programming section.

This is very deep material for a programming newbie to learn outside a course, but for an experienced nerd who's looking for a systematic framework, it's absolutely terrific. I had done lots of lisp and compiler work before reading the book, so many of the concepts were not new. But it's with this framework in mind that I learn new technologies, and this approach greatly speeds up how long it takes to understand each week's "new" hot product/language/tool/mindset. Put another way: why do so many popular computer books take 1000 pages to describe a few trivial concepts?

The reviews of this book are just hilarious; I've never seen a book with reviews so sharply polarized between one and five stars. I think the reason for this is that most of the one-star reviewers had this book rammed down their throats in an introductory CS course, and it blew their minds. This doesn't surprise me; despite the fact that the book is meant to be an introduction to computer science, for most students it will be just too abstract and too difficult. I've been programming for over ten years, and I had to work really hard to understand a lot of the concepts presented here. Nevertheless, I think this is a great book because it discusses lots of ideas that receive inadequate or no coverage elsewhere. The material on compilers, for instance, is difficult (and idiosyncratic because they're compiling scheme, which has its own pecularities compared to, say, compiling C) but if you can work through it you get a pretty deep understanding of what's going on, without having to get bogged down in parsing or other trivial stuff. My suggestion: DO NOT read this book if you are just learning how to program; come back to it after a few years of experience and it will stretch your mind. Also, if you're having trouble I recommend Harvey and Wright's "Simply Scheme" as a much gentler introduction to the same material.

The reviews here that complain that there isn't anything to learn in SICP, or that there aren't any ideas, or that there's nothing but philosophizing and handwaving, are bizarre.

SICP is full of detailed, complete examples of parsers, interpreters, compilers, and digital simulators. It shows how to build your own object-oriented programming system from scratch. It shows how to construct a extensible database query language with a backtracking search to find the answers to complex queries. It shows how to build an optimizing compiler.

Sure, none of this is useful---if your goal in life is to grind out CGI scripts. If that's who you are, this book definitely isn't for you. But the folks who don't recognize the SICP examples as real, practical programming projects are living in a funny little fantasy world. They might use the optimizing compiler every day, but it doesn't occur to them that someone actually had to write that optimizing compiler. Nope, code generation and peephole optimization techniques are not applicable to the real world because `nobody' writes compilers.

Every one of these big, complex programs is explained in detail, with *complete* code examples. You can type them all in and run them. These are big projects, and there's a lot of code, so you shouldn't expect to understand any of the examples on the first glance; you have to study it closely to understand how the parts interact.

If you're looking for silly little toy examples that fit on one page, this definitely isn't the book that you want. I get the feeling that a lot of the one-star folks are after little toy examples. Maybe they want a CGI hit counter or something.

I don't know how well this book works as an introductory book; I had already been programming for about fifteen years when I first read SICP. So perhaps the criticisms that it isn't properly aimed at beginners are on target. But the other criticisms, that say that ``There is absolutely nothing interesting here. Just a couple of bored MIT professors trying to teach extremely boring and pointless concepts'' really miss the mark. Sure, building an object-oriented programming system is a boring and pointless concept---if you happen to be a ditchdigger. But what if you want to be the person who constructs OO programming systems? Or what if you want to extend the OO system you usually use with new features? What if you *don't* want to open up a can of precooked beans and heat them up on the stove?

There are two kinds of reviews on this page. One kind is from people who say that the book is pointless and there's nothing useful. The other kind is from people who say that the book is full of useful, concrete examples.

Maybe the people who found the book useful were suckered. But how can you trick someone into thinking that something pointless and empty is actually useful? That's a hard trick to play! How could there be so many people wakling around, doing their programming jobs, *thinking* that they're using techniques and strategies that they learned from SICP, when actually there was nothing there at all? Where did those techniques come from, then?

On the other hand, another explanation is that maybe those people who think that the book is pointless and empty just missed the point. That seems more likely, doesn't it? People miss the point of things all the time. They read a little to quickly, or a little too carelessly, and the explanation or relevance goes over their heads. That happens every day.

When the reviewer says that `nothing in the book is applicable', that could be a problem with the book, or it could be a problem with the reviewer. My vote is for problems with the reviewer.

I have very mixed emotions about this book. On the one hand, it is perhaps the best introductory work on the philosophical and theorectical issues of computation, dealing with many concepts that normally are either taken for granted by most programmers, or else are completely unknown to them. If you get past the dry, analytical tone (and the rather flat punnery), it actually becomes quite engaging. It is a book that demands careful thought on the part of the reader, and can reward dilligent and thoughtful study. It scrutinizes even such seeming obvious concepts as recursion and assignment, and often reveals a great deal of hidden complexity to them.

However, by itself it is not a very good primer to progamming, either in theory or in practice. The examples given are often unnecessarily tortuous, especially given the imperative to teach strict functional design in the first several chapters. Too much effort has been given to keeping it at 'pure' and 'general', and there is little attempt to connect the important ideas with how they appear in actual use.

Among the flaws is too great a concern with language independence, and specifically, an obsession with presenting the fewest possible language constructs needed to achieve a given purpose. It makes no attempt to present the Scheme language itself except where it is absolutely necessary in order to give an example; while this is done to keep the discussion as general as possible, it often has the effect of confusing the student. Many example programs which would be crystal clear with the use of certain language facilities are made hopelessly incoherent because the authors wanted to enforce 'language independence'.

Also, because many aspects of the language are ignored as irrelevant, the students learn only a small part of the language itself, and are left with the impression that Scheme is a hamstrung, pedantic language lacking in many obvious features. From reading SICP, few would ever imagine that it supported strings, characters and vectors, or had an iterative construct (do), an escape mechanism (call/cc), a macro facility (let-syntax and syntax-rules), or even basic stream I/O (read and write). Scheme is a simple enough language as it is; it need not be pared down any further no matter how noble the purpose.

More importantly, much of the presentation so abstracted as to be completely divorced from real practice, especially in the sections on imperative and OO programming. While this is a good thing in many ways, as it shows the conceptual underpinnings which are so often lost in day-to-day programming, no attempt is made to draw a connection between the theoretical abstractions and the concrete practices. The ideas are left floating aimlessly, and the student is left with no clue as to their relevance or value - which is a pity, because they truly are important, and understanding them can make the difference between a true programmer and a mere coder.

The section on logic databases is an excellent example of this. While it presents all the elements of keys, querying, unification, etc. in a lucid, detailed fashion, the databases are represented solely as list structures. No mention of files is made at all, in this section or anywhere else in the book - the word 'file' does not even appear in the index. Nor does it reveal that most database work today is based on the relational calculus, not predicate logic.

Similarly, the discussion of streams concentrates solely on their use as a way of representing change in state over time; not only are ports (Scheme's stream I/O mechanism) ignored, at no point is the student given any hint at all that the primary use of streams is for input and output. This is like discussing driving without ever admitting the existence of roads; it is abstraction run rampant. While the discussions are wondefully insightful, the student isn't given any way to apply them, even within the context of study.

In the end, I would strongly recommend this book as a supplement to an introductory course based around another Scheme text, such as Simply Scheme. While I think that every serious student of computer science (as independent from software engineering) should study it, really requires the work of a gifted teacher to make it clear, and it should never be used as the sole text. It is a brillant piece of work, and a wonderful source of key insights into programming, but it does not stand alone.

Read this book if you want to understand the difference between "coding" and "software engineering". Read it if you believe that, in order to master the craft of computer programming, it is necessary first to understand the principles that underly how we use computers to automate reasoning. Do not read this book if you just wanna "write code". Such readers will not understand the book, and it will just frustrate them. Instead, read any one of the many books with titles like "Teach Yourself C++ in 21 Days".

And judging by some of what the negative reviewers have said ("scheme doesn't have iteration, just recursion", and "just a lot of theory", and "learn a more common language like C++") if you do not understand this book, do not ask me for a job. Instead, go on believing that today's most fashionable language is superior to all others and that learning syntax is the most important thing you can do.

This is a challenging book. It is not a cook-book of algorithms, and it does not contain one example that people who advocate practice over theory would label "real world". Instead, it gives readers the mental tools to create algorithms when the cook-book is inadequate.

But it ain't perfect. With the exception of one small example, the book does not go into the compromises that digital computers make (precision in floating point math, for example).

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.

Barry Mazur (talking about mathematics, not programming) once characterised the encounter with a genuinely new concept in terms of Gabriel Garcia Marquez's experience on reading the first lines of Metamorphosis, when he literally fell off the sofa in shock, thinking 'I didn't know you were allowed to do that'.
I still remember the same shock, even if I didn't literally fall of my chair, when, as an undergraduate, I encountered the first edition of this on the new acquisitions rack in my departmental library: I must have been the first person in the University, in Northern Ireland even, to read it, which I did, from cover to cover, over several days sitting in the library, even before it was released into the stacks.

The reason why Structure and Interpretation is the best there is, is that it manages, not just once, but several times, to deliver that fall-off-a-chair intellectual jolt. People who complain that you can only do such things in Scheme, and therefore that the ideas are pointless, are missing the point.

Frankly, I'm appalled at the elitists comments made by many of the 5-star reviewers. It's that very superior attitude which prevents the comp-sci field from creating more scientists rather than code monkeys and justifies poor pedagogy and technical writing for the sake of "scientific integrity."

SICP is neither masterpiece nor pariah. No other introduction to computer science has a truer grasp of the "soul" of computer science. Not only that, but there is ALOT of useful theory in here, if you have the patience to look.

But, the book suffers for dreadful writing and advocacy of a language that can be really quite a horror for beginning programmers. On one hand, the authors took an approach that should have been brilliantly successful. On the other, they did a terrible job explaining fairly simple ideas (or, rather, ideas that should have been simple.)

But, the truth is SICP has SO MUCH to offer. Unfortunatedly, the book is only as educational as the CS professor who teaches it. It turns out that the Berkeley professor who said that SICP is "the greatest CS book ever written" is the finest CS teacher at Berkeley. Unfortunatedly, most CS professors are not even 1/10th as good as he is and therefore help make SICP a tortorous excursion.

As a EECS major at Berkeley, I've come to realize just how important theory is in the field of CS. And to that end, I think it is as easily critical that theory should be taught with the utmost respect, not only for the field but the students. SICP is a brilliant master, but often a contemptuous teacher.