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.

That would be a valid argument if the GP was a physicist, I guess. Why should GR be a prerequisite for CS?

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.

He said it was a sarcastic example. As far as I know, the book doesn't mention general relativity

Because GR is the basis for everything human. See Chimpanzee Politics, Schrödinger's cat, etc.

Why was I downvoted? I believe I made an informed and appropriate point.

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.

This guy gets it :) A familiar problem domain would have made the book very enjoyable.

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.

You can learn some of the concepts of SICP and better understand JavaScript with Fogus's book Functional Javascript:

http://shop.oreilly.com/product/0636920028857.do

I can't recommend this book enough. I'm sure some purists wouldn't put it in the same league as SICP, but I think you might like it.

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.

And then you will feel awesome.

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.

http://www.amazon.com/Engineer---Training-Reference-Michael-...

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.