The thing that really turned me off of this book is that the exercises are way more complicated than the material itself. They made me feel like an idiot and like I wasn't learning. To put it in terms of Kathy Sierra, this book didn't make me feel like "I'm awesome"[1]. Here's a satirical example:
> Now that you've learned how to sum an arbitrary list of numbers together, use this knowledge to prove Einstein's general field of relativity.
How about instead of proving physics theories, we use our new knowledge to add together apples and oranges? That is easier for me to comprehend.
I'm not saying this to troll. I know this book is supposed to be great and I plan to read it again. But I'd like to hear why my complaint didn't bother the people here that did finish and love this book. Should I just ignore the exercises?
---
Edit: I want to clarify something. It wasn't that the exercises were too hard to answer. My complaint is that I couldn't even comprehend what some were asking me to do. To me, it was like the exercises were written in French, a language I don't speak. If I could understand what the exercises were asking for, then I could have realized I'm missing something and re-read the section. But as they were written, it made me feel like I should temporarily put the book down and re-take physics and calculus.
That is the difference between computer science as an academic subject and programing as a profession. The attitude was "we expect you to learn the language, that's easy. Now we are going to make you actually think about hard problems."
The book is not "The Structure and Interpretation of Rails/Flask/Struts/Ysod CRUD Apps" for a reason.
I don't really get what your comment has to do with what I said. It seems like a strawman pretending I said, "This book is stupid, I read 100 pages and I still don't know how to make a game!" Or, "this book is stupid, I read 100 pages and I still don't know how to connect to a database!" I'm not even complaining that the exercises are hard, I'm complaining that they're incomprehensible to me.
Also, since you've pointed out that the book is called "The Structure and Interpretation of Computer Programs", wouldn't it make more sense for the exercises to be about computer science things instead of math and physics? I own The Art Of Computer Programming by Knuth and it has plenty of exercises in it that are both computer science related and make you think about hard problems.
Well, this is a book written by MIT professors in support of an MIT course. Students will be concurrently taking classes in these other subjects. Which makes it a great undergrad text for an engineering school, and probably pretty tough if you don't have the math and physics background.
I voted you back up. But the answer to your question is 'for the same reason you don't teach GR as a prerequisite to tying shoelaces.' Small children and shoelaces wouldn't be here without GR either, but it's just too abstract for most people.
The problem for the poster above is that if you read SICP outside MIT or especially outside college, you're not surrounded by a bunch of science nerds who can be persuaded to explain general relativity in return for beer and a pizza. If you're not swimming in a sea of science, then problems involving the behavior of fish seem much trickier to solve. I've seen this problem iwth a few other MIT books, eg Horowitz and Hill.
Horowitz and Hill? Hmmm, I don't remember running into any out-of-domain stuff whilst working with that book at uni, but then maybe that's your point - I was at uni, so it fitted nicely, but for someone coming at TAOE without an engineering background might struggle. Do you remember any concrete examples? Was it something like needing to understand wave propagation to understood why the modulation circuit worked, or things like that?
I'd have to go and dig out my copy now to check. The main things I remember offhand were problems with no discussion of the answers, and examples of 'bad circuits' which you were encouraged to build to find out why they went wrong. Great if you're in a class, not so great if you're studying alone.
If I recall correctly, the book does mention that it was designed with students at MIT in mind. I also recall that the students finish a couple calculus courses before taking the SICP course, so the math contained therein isn't exactly new material to them.
For the most part I believe you're mostly complaining about chapter 1 though, maybe chapter 2 when they talk about painters and the exercise with the chessboard. Those are two that come to mind that tend to be excruciatingly long and unnecessarily difficult for beginners. I would advise you to go through the book again, and while this does come off as somewhat snooty, I would say that if you don't understand the math or physics behind some of the exercises, then you should spend time trying to figure out the algorithms for them. Most of the value of the book is actually through the exercises, as typically those are the spots where you'll eventually start to have those "aha!" moments when working with scheme.
As a disclaimer, I should point out that I had quite a bit of programming experience in C++, Python, and other OOP languages before trying SICP. Luckily, I never struggled with the math, and learning Scheme came quite naturally. However, the common problems associated with thinking in Lisp do apply, and it may take several cracks at the book before you really understand the beauty or essence of what SICP tries to teach.
The point of the exercises is that the book is trying to demonstrate a WAY of thinking. No amount of passively watching words pass by while you nod sagely at how obvious it all is is going to make your brain actually try to think that way.
My experience is that once I actually understood the section, the exercises were usually not that hard. However it was very easy to read a section and only think that I understood it.
I agree, and I love SICP, but it also assumes a general familiarity with undergraduate-level mathematics, up through calc 1 and linear algebra, as well as some basic number theory, that many people probably do not have and will immediately be intimidated by. Even though it does not rely heavily on these subjects, they are strewn throughout the work: the book was written at a time when the sole academic path in computing was as an engineering discipline, and the students all had a common background. The field of programming and, I would argue, computer science at large, is much more diverse now, and I think the text could have a broader reach with slightly different examples and exercises, and perhaps a bit more elaboration. Learning to model problems when you are both unfamiliar with the problem domain and the modeling tools is daunting, to say the least.
Take this with a grain of salt, but IMO the reason some people who try to learn programming end up with this type of mindset is because they have a wrong mindset to begin with: they believe learning to program should be relatively easy and have an obvious and relatively simple path to mastery. From my experience, this is not the case at all. If you read any math textbook, generally the last problems in a section are the most difficult to understand and answer, unless you've mastered all the concepts in that section. Pure Computer Science is harder than pure math in many ways; 1) because unless you master all the concepts in a section, you won't get too far, and 2) computer science in general, but specifically this textbook is geared toward people who have already somewhat mastered mathematics, so all or most of the problems will be like the last problems of a section in a math textbook.
"If it comes easy, then you're not doing it right."
> they have a wrong mindset to begin with: they believe learning to program should be relatively easy and have an obvious and relatively simple path to mastery
The masters of every subject say stuff like this, and it's really just a type of myopia of the craftsman. I work in manufacturing and people tell you shit like this all the time.
Imagine a 19th Century Car Driver:
"People who think learning to drive should be relatively easy are missing the mastery required for match-rev shifts, air-fuel mixture, spark management - not to mention the intricacies of debugging your carburetor on the side of the road."
Programming will continue to be made more accessible, as is the apparent trend. Nearly no developers know what's really going on under the hood except people who specialize in assembly, CMOS, etc.
> Programming will continue to be made more accessible, as is the apparent trend
Of course it will become easier over time...just like everything. Consider John Carmack and what he did when writing Doom, Wolfenstein, etc...I can almost guarantee you when he was programming, programming was A LOT harder than what it is today. But the difference there is nothing more than time. Even if it's getting easier over time, my main point still stands.
I'm not sure I agree... While it's certainly true that to create the same thing that Carmack did would be a lot easier today. Working on Carmack level code remains very difficult to this day. It's just that the bar has moved.
Sure, a simple ray-caster isn't going to need a lot of optimization today. But when you are dealing with the sort of data that is now common. Optimization can be just as important.
While languages have have improved for the better, other things have created other challenges. Consider the PS3 Cell architecture. Considered to be a much more difficult architecture to program for than the processors of Doom's day.
If you're satisfied to write e.g. RoR apps for a living and have no curiosity in programming beyond that, I agree that SICP will not be very valuable to you.
There's a psychological threshold. If something is made easy then you'll have almost no reason to make the effort to go knee deep and back up again into abstraction when needed.
> "If it comes easy, then you're not doing it right."
I don't like that advice at all. Sure, not everything's easy, but the hard way is almost certainly not the right way. When I was learning to program (still am, as should all of us who are programmers), pointers came easy, arrays came easy, hash maps came easy. Almost every concept makes sense. I'm not some intellectual godsend either, so I know there are probably a countless amount of others who feel the same way.
I think that the most likely option is that the "teacher," or at least method of teaching, is bad.
It's also possible that the teacher, or the method, is simply a bad fit. I watched some of the SICP lecture, and they, and the book, are a bad fit for me, partly because I lack much of the math background. I'm sure there are other people for whom they're perfect.
I think you definitely have a point -- but there's a case to be made for including some hard material in the text, and including some easy exercises.
Indeed: Hard exercises have an important purpose. They are about problem solving. But so do easy exercises. They force you to make sure you understand the basics of what you're doing, and suss out bad habits before they become ingrained.
The sure fire way to become a lousy programmer is to learn programming without some domain to apply it in. Given that MIT undergrads have a fair amount of math and physics backgrounds, the exercises aren't a bad fit at all (methinks). I always find it energizing when textbooks include problems with an "oh, by the way, this is an unsolved problem in the field" note.
The good professors also appear to be carrying that tradition into the revised course ... and the most public attention goes to the switch from scheme to python.
SICP carry some baggage I believe. Abelson and Sussman are Electronics Engineers, fond of mathematical way of thinking and culture thus applying computing to think about these fields. I think that's one reason behind the creation of How to Design Programs (HtDP, by Felleisen) which deals with abstractions and recursive problem solving but without involving complex maths or physics. Later on, you might appreciate SICP problems with less resentment.
One of the unspoken premises of the book is that learning to program requires learning how to deal with new knowledge domains. SICP doesn't require mathematical sophistication - math is just another knowledge domain and not much different from the graphics domain in Chapter Two or the banking examples in Chapter three.
In some ways mathematical knowledge is even easier to obtain since the same logic underpins it as the lambda calculus upon which scheme is built.
That's not to say that some of the exercises don't rate 28 on the Knuth scale. But I don't think there are any 34's or higher...and it goes without saying that the Donald definitely throws in whatever math might be needed regardless of the reader's experience. And yet this doesn't make TAOCP inaccessible.
Well, it might be the case that you were lacking some assumed prerequisites (don't forget that the book is aimed at MIT undergraduates, who will have some background in math and physics).
But if you cannot relate an exercise to the subject matter you just studied, it might also be the case that you think you understand what you just read, but don't really do. It's easy to read math superficially, honestly believing that one has understood the point, when in fact the "mental image" the authors wished to impart on you has not been grasped.
So you should not ignore the exercises, but work hard at them. They (well, some of them) are supposed to be hard. They are supposed to make you think, not just rehash what you just read. And after all that hard work, hopefully, something will click and you will be ready for the next section.
You should probably have a copy of the Engineer-in-training handbook. This is a tremendously useful tome as it's written to provide the tools for solving problems, as opposed to theorizing about how problems ought to be solved. So while it's 'bad' from a pure math/physics standpoint in that it invites you to take things on faith rather than learning to derive them from first principles, it's great in terms of teaching you how to apply the fruits of these disciplines.
The exercises are amazing, and they give you a chance not just to grapple with the language but to think about some fascinating problems and in some cases learn new material outside of the text proper. It's assumed that picking up the syntax of the language will be the easy part. Some of them are pretty hard, but they are always more or less direct applications of the ideas discussed in the previous section or two. Relativity is not really in any sense a direct application of addition.
That said, the book is definitely written for those who have an undeniable aesthetic sense for beautiful problems.
It would be good to read it with a different mindset. Learning something requires you to feel stupid for a bit, otherwise it's no great feat to learn it (and consequently feel awesome). The problems are all doable, given the expected background of its readers, just not easy or straightforward. If you ignore them you're missing out on 75% of the material - a lot the hard problems require you to apply something from the text that wasn't spelled out for you explicitly.
I didn't ignore them, that's why I eventually gave up. I really enjoyed the book material and the exercises I could understand. But when I ran into an exercise that made me feel like I need to take a non-programming course to comprehend, it was really demotivating.
I suspect that, for many people who love this book, the answer to why your complaint didn't bother them is simply that they don't share the complaint. I certainly don't remember thinking the exercises were of a different level than the main text, or off-topic, or confusingly worded. So it's not that having exercises "that might as well have been written in French" doesn't faze me, it's that I don't think that was the case.
The goal of the book is not to "make you feel like you're awesome". I liked the more complicated exercises because it forced you to understand the associated concept well, attempt some problem-solving and get better at writing Scheme.
It seems to me that Peter Norvig is attacking personally the readers who didn't like SICP (in the lines of "if you didn't like SICP, you're just not a creative person").
Also, he is flawed when saying that only about 1 person out of 50 should like this book (the proportion of people who have "this strange way of thinking that makes a programmer"), since the largest part of the people exposed to SICP are programmers, or at the very least interested in computer science.
Disclaimer: I have lots of respect for Norvig and think his PAIP is awesome.
I'll add my support for this, in general, since there are so many dissenters:
Norvig doesn't do anything to address ones that think the book is poorly written or gives bad advice (for modern times) or confusing in style, for instance, just claims the 1-stars aren't looking for the same information as the 5-stars.
This amounts to "the book is perfect. your review tells us who you are." which is an extremely-limited-use stance when it comes to critiquing, and simply insulting to anyone who wants what it's offering but doesn't like the presentation.
His analogy is that some people want to know exactly how their car works, but most people just want to drive. I don't think that's an attack on everybody who's not an automotive engineer.
Also, he is flawed when saying that only about 1 person out of 50 should like this book ... since the largest part of the people exposed to SICP are programmers
He acknowledges that by saying "a big part of the explanation is that the audience is self-selected." But he also seems to be acknowledging that not every programmer needs or wants the depth that SICP provides.
The passage in question, as neither of you seem to have read it closely:
> 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.
I read it closely the first time, thanks. If you'd like to directly address something I said, feel free.
Although, I only said two things, (1) he acknowledges the audience is self-selected (direct quote from the review), and (2) some people aren't willing to put in the work to gain that level of familiarity with the subject (directly supported by his analogy in the second paragraph).
Does that contradict anything in the review? You seem to be fixated on something else there that S4M and I aren't discussing. If you'd like to draw attention to that, again feel free.
It seems like you may have read too much into his review.
Sometimes people do just want to learn how to drive a car, not how to assemble one from scratch or whatever. If you're expecting the former and you get the latter, it's understandable why you'd be frustrated. There's nothing wrong with that and Norvig doesn't say there is.
I do not understand your criticism of the 1 in 50 quote from Knuth. He's not saying only 1 in 50 are suited for programmers (and therefore everyone who isn't is wrong).
He's saying the set of people who think like that is larger than 1 in 50, as evidenced by 25 5-star reviews. The implication is that if you think like Knuth, you'll enjoy SICP, which doesn't seem that far from the truth, considering how esoteric Knuth and SICP may be for some people.
I read the first three of five chapters of SICP (along with the MIT lecture videos) in high school and loved it, but I totally disagree with Norvig's car analogy. I did not care for SICP because it told me how computers or even computer programs ran. I cared about it because it made me think differently. It is a book for how to think about these classes of problems, not a book on the inner workings of complex programs.
At least, that's what I got out of it the most. I've always been on the theoretical side of things.
That reminds me one of the argument Newton made in his Principia. He said something of the essense that he has intentionally written his Principia in non-friendly dry manner because he wanted readers to have certain degree of discipline and patience and also he wanted to eliminate readers who would just naively attack his works with shallow arguments.
But that was than. Today readers have came to expect certain level of accessibility. But still no one should tell authors how they need to write books. If you think SICP is not accessible enough, go annotate it with your insights and expanded arguments filled with analogies and examples.
> An optimistic professor somewhere has been feeding SICP to undergrads who are not ready for it.
In my very fist undergrad class, this was the course textbook. I generally think that I and some others taking the class at that time didnt value it so much, but going forward (especially after the class) I feel like what it talked about is a lot more important than I initially thought. I think that the professors made the right decision, though, giving us the book that early because even though I didnt appreciate the book so much then, I think that I absorbed a lot of its ideas into the way that I code.
The reviewer accuses the 5-star reviewers (not PG and Peter Norvig directly, since that review seems to predate theirs, but that hardly matters) of elitism, and the book itself of "dreadful writing", "advocacy of a language that can be really quite a horror for beginning programmers", and "a terrible job explaining fairly simple ideas".
I'm tempted to say "Yeah, well, that's just, like, your opinion, man."
This reminds me a bit of something a chess teacher named Richard Shorman said. In the late '80s and early '90s, Shorman was at the LERA chess club in Sunnyvale where each week people would bring their games and Shorman would go over them and advise them how to improve.
Shorman was particularly good at getting players who were stuck in the 1800-2200 USCF rating range moving again. One of the big reasons people get stuck is that they are trying to play too good. They are trying to apply deep positional concepts they learn from reading annotated grandmaster games, or reading books with titles like "Play Like a Grandmaster!". They are planning openings developed by grandmasters for use against grandmasters.
That's fine for grandmasters--because grandmasters UNDERSTAND what is going on. All of those deep positional concepts that shape grandmaster thought are ultimately designed to lead to a tactical advantage over their opponent, or to prevent bad tactical things from happening to them. To understand the positional stuff, you have to thoroughly understand the underlying tactics.
Shorman would steer these stuck players toward a more aggressive approach. Play the most aggressive move they can (that you can't see an outright refutation for). Open with gambits that give you a good attack.
This worked. As the stuck players got used to the sharp games that arose from this style of play, and came to really understand how the pieces worked tactically, they'd start understanding positional play, and be ready to move toward playing good chess.
The way Shorman put it was something like this (paraphrased since I can't remember it exactly): before you can play good chess, you have to get good at bad chess.
Im guessing youre being sarcástic, but Basic should not be visited upon any human you wish no harm done to. It was a pox on a generation of programmers, foisted upon us under the guise of 'lets expose kids to computers! Thats a Good Thing!'
[...] a very particular piece of grammar, expressing a nuance
that standard English leaves to context. Black English is a seemingly still
water that runs deep.
I found the oppose to be true. The more the different things you exposed to, the more you can borrow to reflect on the new material. Exposed to a different paradigm like OOP only helps.
Developing a useful, general framework for expressing the relations among different types of entities (what philosophers call ``ontology'') seems intractably difficult. The main difference between the confusion that existed ten years ago and the confusion that exists now is that now a variety of inadequate ontological theories have been embodied in a plethora of correspondingly inadequate programming languages. For example, much of the complexity of object-oriented programming languages -- and the subtle and confusing differences among contemporary object-oriented languages -- centers on the treatment of generic operations on interrelated types.
I don’t quite get the last bit. Why is "centering on the treatment of generic operations on interrelated types" inadequate?
Do they talk about the tree-like structure of inheritance which might be useless in scenarios where the relations can be better modelled by an arbitrary graph?
Also, why would studying OO first be narrowing my ability to learn different paradigms?
I don’t quite get the last bit. Why is "centering on the treatment of generic operations on interrelated types" inadequate?
Go to the link, and find what it was a footnote on. You'll be reading through a section that is attempting to make operations like addition work in a reasonable way across different numeric types for an abstract math package which needs to support integers, rationals, floating point, complex analogs of all of the above, polynomials over all of the above, and lots of other fun stuff..
Do they talk about the tree-like structure of inheritance which might be useless in scenarios where the relations can be better modelled by an arbitrary graph?
Also, why would studying OO first be narrowing my ability to learn different paradigm?
Because your mind naturally goes through prepared channels. If you've got OO available to you, then you naturally solve the simple versions of problems with OO. Then when you get to the subtleties of the complex version that your form of OO doesn't work well for, it is hard to see that OO isn't a good fit, rather than being trapped into thinking that you just chose a poor initial model.
Everyone here seem to think its take it out leave it, eat all of it or nothing. I don't agree. Get the book. Sneak in when you have an hour left without forcing yourself. You might get hooked as I have been. Then you'll find more hours for it. Do or don't do the exercises, it's not important. If there is a couple of paragraphs you don't understand, don't worry, skip forward a bit. If you feel it's going too deep just hang up. Maybe one day you'll come back to it.
Oh, and don't overlook the footnotes, some have very interesting bits.
I don't know about TAoCP but SICP has been available in electronic format for some time. They released the full book as HTML [1] but others have taken to formatting it in Mobi [2], PDF [3] and even a "Pocket" edition [4] formatted for small devices.
Thanks for that. When it wasn't available in kindle on amazon, and TAoCP having not made the jump from paper (pdfs don't count. They are a terrible format for books), I assumed that it was likewise unavailable.
The Art of Computer Programming in PDF form can be found on The Pirate Bay, and I encourage anyone who can't afford it (students, programmers between jobs, etc) to download it. But if you feel you learn anything from it, then you must buy it later once you have the income.
Also, it's probably ethical that if you've bought TAoCP, then it's ok to download it in PDF form. Some people like PDFs instead of hardcopy.
I find PDF formatted books so difficult to use, I will reach for the paper version first :( But as discussed above, SICP does seem to be available in a convenient digital format.
Thanks. When it wasn't available in kindle on amazon, and TAoCP having not made the jump from paper (pdfs don't count. They are a terrible format for books), I assumed that it was likewise unavailable.
Whenever one is ready to devote some time and brainpower to mastering its concepts. It moves pretty incrementally, and there's nothing in there that's impossibly complicated to understand. It does probably require a bit more mental effort than understanding your typical OO paradigm. It's a great book--I highly recommend giving it a shot.
The external metric that one can use is: "did it make my code and my ability to explain things less complicated and more understandable to other people".
If yes - that person was ready. If no, if as a result both code and the language of that person got filled with formal and obscure complications... then no. Not ready.
Al would be "others", and appears in lower case because it is not a proper noun.
Strictly speaking, al. is actually an abbreviation that could mean any of the Latin words alii, aliae or alia. Which one is appropriate would depend on the gender(s) of said others.
Ah, of course, thank you. I didn't see it anywhere on the review page or the main Amazon page for the book, so it threw me off. I was afraid I was going to have to finish SICP before I'd get this reference. :)
I used SICP as a template for writing a Scheme interpreter in c++. For that, it was awesome. Once you implement an immutable list and an immutable map in c++ you can write nearly homologous code to that of the scheme in SICP. Name how many programming books teach you a language, a mindset, a bunch of usable algorithmic constructs and to top it all a recipe to create an interpreter for the said language in any computational substrate.
Lots of big hints there for forward thinking developers to pick up on. Haskell for a large simulation project, GPGPU shared memory datastructures, 120 hz clock with physics interpolation, benefits of functions without side effects, performance benefits from elegant design rather than complicated optimization kludges.
Thanks for posting this, it convinced me to finally crack this book. I've done a little bit of toying around with Racket and Clojure, but I don't feel like I understand how these languages work deeply enough on a conceptual level yet.
I'm going to name my kid "al Arthur Alexander", so he can claim authorship credit for thousands of writings, and also for millions of highscores in arcade cabinets everywhere.
> Now that you've learned how to sum an arbitrary list of numbers together, use this knowledge to prove Einstein's general field of relativity.
How about instead of proving physics theories, we use our new knowledge to add together apples and oranges? That is easier for me to comprehend.
I'm not saying this to troll. I know this book is supposed to be great and I plan to read it again. But I'd like to hear why my complaint didn't bother the people here that did finish and love this book. Should I just ignore the exercises?
---
Edit: I want to clarify something. It wasn't that the exercises were too hard to answer. My complaint is that I couldn't even comprehend what some were asking me to do. To me, it was like the exercises were written in French, a language I don't speak. If I could understand what the exercises were asking for, then I could have realized I'm missing something and re-read the section. But as they were written, it made me feel like I should temporarily put the book down and re-take physics and calculus.
[1] http://www.youtube.com/watch?feature=player_detailpage&v=eSl...