Hard Books Are Overrated
rs.io
rs.io
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.
"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.
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!"
"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."
Good god.
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.
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.
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.
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.
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.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.
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.
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.
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.