I read about half of SICP and thought it was OK. Not great, but okay. The programmers I've met fall largely into two groups, those who like systems level programming, knowing how the OS works, how it interfaces with the hardware, what the memory layout is like, etc. and those who like abstraction and the things that SICP values. I'm definitely in the former group (but I certainly appreciate people who prefer the SICP approach).
There's room for both of course, but for people like me SICP was really a slog. Some of the exercises were hard sure, but more than that the material just wasn't that appealing to me. I don't have any comment on whether MIT's decision was the correct one, but liking SICP or working through SICP is by no means a prerequisite of being a good programmer.
Hmm, I didn't get your dichotomy... By "half" did you mean the first half? IMHO the main dish of SICP is chapter 4 and 5 (ch1-3 is just laying foundations), and the content of latter chapters is strongly connected to system-level things like compilers, run-times, processor design etc.---it's not as immediately applicable as like the Dragon Book, but SICP gives you the perspective, in a sense that it shows broader possible design space within which you can locate the current OS / hardware / language technology.
Yeah I agree that the first 3 chapters are somewhat archaic, and especially if the reader already has programming experience it looks like it is reinventing some mundane features.
The problem is that most programmers today aren't apart of either of those groups but apart of a third, totally separate group: programmers who pick and prod and then glue lines of code together.
SICP is programming for the theoretically inclined. It seems analogous to calculus in math versus calculus for physics: you can study it more formally with all the proper proofs and derivations (and bizarre cases), or pick up just the applied bits (such as chain rule and dot notation) that you need for doing AP physics. This analogy suggests the existence of two approaches, with different implications and consequences for programming culture.
I think that is true to some extent, but Knuth's approach (which I'm more drawn to) is also theoretically inclined, albeit of a different approach than SICP. Knuth (and myself) see programming as fundamentally being about computers, and Knuth starts with what a computer can do and builds from there. Ableson and Sussman see programming as more about computation, so they start with a model of computation (based on scheme, lambda calculus, etc.). These two approaches are quite different and I don't think you can reconcile them easily. Not that either one is all that much better than the other, though Knuth's is certainly more efficient. It seems to me that a large part of which you favor comes down to how you're wired.
Are program meant to tell the computer what to do? (Knuth)
Or are computers meant to execute our programs? (CISP)
Personally I lean towards the second view, for a simple reason: we design programs much more often than we design computers. Computer design doesn't take much of humanity's time, compared to programming them. So I'd rather have the hardware (and compiler suite) bend over backwards to execute our pretty programs efficiently, than having our programs bend over backwards to exploit our hardware efficiently.
>The programmers I've met fall largely into two groups, those who like systems level programming, knowing how the OS works, how it interfaces with the hardware, what the memory layout is like, etc. and those who like abstraction and the things that SICP values. I'm definitely in the former group (but I certainly appreciate people who prefer the SICP approach).
Many of us are in both groups, which is how stuff like Rust came about.
There's room for both of course, but for people like me SICP was really a slog. Some of the exercises were hard sure, but more than that the material just wasn't that appealing to me. I don't have any comment on whether MIT's decision was the correct one, but liking SICP or working through SICP is by no means a prerequisite of being a good programmer.