In mathematics, my experience falls emphatically on this explanation: "Hard texts are that much better than anything else." Books like Rudin's Principles of Mathematical Analysis are mathematics; their more accessible counterparts are more "about mathematics." As to why successful people don't read more difficult books, well, being a great mathematician just isn't that important to success. Reading Rudin sets you on the path to being very good at mathematics, but that isn't most people's goal. If your goal is material success then yes, hard books are probably overrated.
The programmers here may appreciate this analogy: reading Rudin is like reading the source code, whereas more gentle texts read more like documentation or UML. That's not to say good doc can't be enlightening, but in the end only the source code matters. The doc can be wrong, or misleading, or incomplete. If you want to really understand what's going on, you need to read the source. It's the same way in mathematics.
PoMA presents a mathematical approach that's done in countless other analysis textbooks. What people (students) hate is that the author makes leaps in his proofs. But that's not something unique to Rudin's style. And who says these students wouldn't be capable of making these leaps later on? Please explain to me how "Rudin sets you on the path to being very good at mathematics" (more so than any of the "easier" books), if you agree with my claim that there is in fact nothing unique about his book. If you don't agree, please tell me what is unique.
"As to why successful people don't read more difficult books, well, being a great mathematician just isn't that important to success."
???
"Rudin is like reading the source code"
Rudin's book is incomplete to a beginner. The analogy doesn't work at all.
Ah, I think we are responding to two separate issues. I was referring to Rudin as a mathematical treatment of calculus, in the definition-theorem-proof style, to be contrasted with the more popular and easy heuristic approach. I contend that the Rudin style is a qualitatively better way to learn mathematics. It is also undoubtedly harder to read--but that is because it treats the material in a rigorous, correct way, which is inherently more difficult than heuristics.
Your argument is that Rudin is hard for incidental reasons: he skips steps in his proofs. I personally did not feel this way when I read the book. But I am open to the idea that Rudin is imperfect. I personally admire Rudin's concision, but that may just be my personal aesthetic preference.
My point, and perhaps I did not convey it well, is simply that some subjects (in particular mathematics!) are inherently difficult. And if you want to learn them well, you have to face that difficult head on: you have to read hard books. Euclid's old saying comes to mind: "there is no royal road to mathematics!"
I just told you: most analysis textbooks treat the topic in a nearly identical manner (maybe not in full generality). Do you want to dispute this? Why are you pretending like we're arguing separate issues?
"Your argument is that Rudin is hard for incidental reasons: he skips steps in his proofs. I personally did not feel this way when I read the book. But I am open to the idea that Rudin is imperfect. I personally admire Rudin's concision, but that may just be my personal aesthetic preference."
> This one could really go either way. A broad selection of fifty popular science texts will teach a person more than one really hard book
This statement seems obviously false. No amount of reading analogies about science will teach you any actual science. Also, the author seems fixated on measuring learning by "things" (facts?). That's a terrible metric, unless you're trying to collect facts, in which case, you'd probably be better of reading the encyclopedia.
When I was in college, both SICP and Knuth's books were on the recommended reading lists. I didn't buy the former until years later, but did buy Knuth's books (individually and at a time when I could ill afford them) and read them through. They are hard and it was very slow going. There's still a lot I don't understand. But I learned a huge amount, continue to do so and would absolutely recommend them to anyone with enough interest in the field. Similarly, when I finally bought and read SICP, I wondered why I hadn't read it sooner. I still read both books, along with many other "hard" books and enjoy them. I don't think I would be the programmer I am today if I had not read those books.
I disagree with the author. I certainly understand that reading "hard" books takes a lot of effort that may not seem worthwhile, but would not say they are overrated.
However, like anything else, they aren't for everyone. Just those who are ready for them.
I think his success spirals advice is great. You tend to build up skills iteratively and incrementally.
But comparing SICP to baby Rudin is extremely out of point. SICP is a conceptual book. Rudin is a super-synthetic Bourbaki-like text. A lot of intuition has been removed. In general this is bad unless you're going through the topic for the n-th time.
"Easy" is about proximity to the subject (As in Rich Hickey's Simple Made Easy). Hard books are any books you aren't ready for, and I don't recommend them either.
One of the learning buzzwords is "Zone of Proximal Development" which basically means the concepts that are 'nearby' what the learner already knows, and can be learned with help.
The author has some keen insights when talking about Familiarity causing recommendation problems. We compress that knowledge down into a very powerful but compact form, and often have a lot of trouble decompressing it when describing something. "What do you mean, 'what is a function?', it's a function, it just is!"
I also agree that sometimes people recommend books, even books they have not read, that make them seem smart, which is often unhelpful. Other books have useful content, but are just badly written. We use them if we have too, but we prefer better writing.
On the other hand, books like Structure and Interpretation of Computer Programs are beautiful, useful, amazing works that when explored at the right time, can be eye opening, profound experiences.
A given book may be recommended because it is a simple beautiful elegant work. Simple doesn't mean easy, that's separate. You have to be ready for the book and its concepts before you can benefit from it fully. A good book can challenge you to understand simple, but deep ideas. A good book can be a lot of work and exploration, and may go slowly. But a good book at the right time will be worth your while.
So hard books are overrated, but maybe that hard overrated book you rejected before may be more approachable today. Keep in mind when recommending texts to others that they may not be ready for the advanced text yet.
All I can say in reply is that I wish that I had had access to the best presentations of the subject matter that interested me when I was young. I learned calculus from some atrocious "IB HL math manual" over a weekend. I would have been grateful to have had a copy of baby Rudin at that time. Many of today's young (especially in rich areas such as SV) now have the privilege of unfettered and instant access to knowledge, and have been spared the horrors of a public school education drawing on sources full of dumbed-down and inaccurate information. I think this culture is gradually forgetting that the acquisition of knowledge is worth struggling for.
A lot of university students are clueless about this sort of thing. If it's possible to complete the homework by just relying on lecture, then there's no reason to be reading the book. That's a common sentiment, even in some math classes.
Somebody, at some point, declared a book to be "great". And now you have a bunch of people recommending that "great" book because that's all they're familiar with (and why would this top notch faculty force us to use this book if it wasn't great anyway?). Few professors actually make an effort to structure classes in a pedagogical way.
I haven't read SICP (shame on me!), but I didn't think it had a reputation of a "hard book". Isn't it designed to be introductory textbook for freshmen students?
SICP is an interesting case because some of its "hardness" is actually incidental to the subject matter. It is written by, and for, people who enjoy pure mathematics and numerical functions. That describes a lot of incoming CS students, but not all of them.
Almost all the examples in the first few chapters are things like estimating the values of convergent series, and a less mathematically-inclined student will spend more time puzzling over the problem definitions than over the concepts of recursion and encapsulation that the problems are trying to demonstrate.
I think the book would be much stronger with a broader diversity of examples, especially early on. I'm not advocating completely getting rid of the pure-math ones, but a wider range of problem domains would very likely help the concepts "click" more quickly for a larger set of students.
There is certainly the "CS is a branch of mathematics" viewpoint that suggests that someone who hasn't already mastered basic calculus as a university freshman has no business pursuing a CS degree in the first place, but I don't personally subscribe to that idea.
"It is written by, and for, people who enjoy pure mathematics and numerical functions."
The latter wasn't strictly true of CS focused MIT undergraduates back then ^_^, but by definition they could do math at that level. It was a common background Ableson and Sussman could safely assume everyone taking the course could do without much sweat, i.e. it avoided accidental complexity to focus on teaching the CS concepts they cared about. Just like the very simple syntax of Scheme takes a whole lot less time to grok than the Algol family standards, at least of the day (have not learned Python so I'm not qualified to comment there, but from what little I've seen it's still more complicated).
A broader diversity of examples would indeed be a good thing, and I'd be surprised if no one has done some work in that direction. On the other hand, as is it works for any CS program with a strong, non-optional EE component, e.g. MIT and I gather UC Berkeley, and once upon a time as I recall it was the intro course for CalTech, which is a lot more mathematically intense than MIT (when you show up you're expected to know single variable calculus and are dumped into Apostol, with an option to finish in a more applied track, or so was the case the last time I checked a few years ago).
As for your later point, I've very unsure a grounding in continuous mathematics (no matter how fun it is, at least conceptually) is essential for mastering a lot of CS, I thought the most relevant domains were in the area of discrete mathematics, with of course various areas dipping back into continuous math.
Just because it is an introductory book doesn't mean it isn't difficult. It was written as the course text for an MIT course which was known to be quite challenging. MIT has since dropped SICP as the required intro course. It is now an elective. I think the book may not be the appropriate difficulty level for a college freshman who has never programmed before. I got a lot out of it by doing the programming exercises after I had a few years of college coursework under my belt. I don't think I would have gotten a lot out of it had I not had that experience.
It's not even an elective (note its absence here: http://student.mit.edu/catalog/m6a.html). Some grad students who love it teach a portion of it to anyone in the January "Independent Activities Period", and the first ~30 students who sign up and do the problem sets can earn less than half of the credits of the original course.
I.e. tolerated by the department, but no more so, and may well die as those passionate about SICP leave the Institute. Promises to offer it as an elective, especially for all those outside the department who can benefit from it, unlike the new intro courses which intertwingle EE with CS, were empty, and were obviously so at the time.
> I haven't read SICP (shame on me!), but I didn't think it had a reputation of a "hard book". Isn't it designed to be introductory textbook for freshmen students?
The two categories are not mutually exclusive; indeed, I'd expect the core textbook of any not-expressly-for-students-of-unrelated-majors introductory class in any field at a top-tier school for that field to be something of a hard book.
The programmers here may appreciate this analogy: reading Rudin is like reading the source code, whereas more gentle texts read more like documentation or UML. That's not to say good doc can't be enlightening, but in the end only the source code matters. The doc can be wrong, or misleading, or incomplete. If you want to really understand what's going on, you need to read the source. It's the same way in mathematics.