I basically agree with the OP that Dive into python is a pale replacement, but at the same time there is something to SICP's critics. Peter Norvig seemed to think most people would get the most out of it after getting some experience, and the HtDP authors definitely have a point about how much heavy math is involved. It's still a wonderful book, and won't be lost, I'm sure.
"Peter Norvig seemed to think most people would get the most out of it after getting some experience,"
I have to strongly agree with that. In general, you can't understand a solution to a problem until you encounter the problem yourself, and SICP too many solutions, too quickly, for problems you've never encountered, for it to stick very well to a novice. It may seem strange to criticize something for student use for having "too much solution in it", but based on what I've seen it's the truth. It would be a better junior or even senior level course than a freshman intro, when you have something to hook the solutions on to. Or an honors freshman course, for people you know have done some prior programming.
> ...and the HtDP authors definitely have a point about how much heavy math is involved.
I get why people object to heavy math in programming -- it makes the entire field less accessible -- but programming is heavily based on mathematics, if not entirely a subset of mathematics. Saying, "it requires too much math to learn this" strikes me as a lot like saying "there's too much biology in learning to be a doctor".
I strongly disagree that programming is heavily based on mathematics. Rather, mathematical formalisms exist for much of programming, and the better our programming languages become, the more heavily they are based on sound mathematical concepts, because mathematically sound concepts happen to have desirable qualities around consistency and orthogonality.
But simple imperative programming at the level of assembler, for example, I would argue is more closely related to cooking recipes than it is to mathematics. And the reverse mapping of mathematics to programming isn't terribly strong either; most general-purpose programming isn't abstract enough to get big gains from maths.
As a practical matter, I work professionally on compilers - i.e. far closer to the CS end than the glue code end of things - and outside of the usual bits of parsers and grammars and graph theory, I would still submit the only really important piece of CS maths a self-motivated student programmer needs is the analysis of algorithm complexity; big-O notation for space and time, in other words.
All that said, I'd prefer by far students being taught from SICP or CTM[1] than any book targeted at introducing people to a programming language, rather than using a programming language to introduce people to CS concepts. Using practical, industrial languages like Python or Java warps your perspective because in the interests of practicality, those languages are quite opinionated in how you should structure your programs. Things are different with Scheme or Oz.
[1] Concepts, Techniques, and Models of Computer Programming
Ugh. I don't really understand the criticism of too much "heavy math" in SICP. The calculus involved is very basic. The rest involves infinite sequences and series, which are pretty fundamental to Computer Science. Really, students only have to have brushed up against derivatives and have a basic notion of what integrals are to complete SICP.The amount of "calculus" that SICP requires can be learned in a fun-filled afternoon.
I completely agree, but at the same time, it's a barrier to entry that I think might be unnecessary. Some college freshman haven't taken calculus, and SICP would seem a bit daunting at times to those students, I imagine. Unfortunately, I think HtDP goes too far; it's too dumbed down.
Yeah, and that's a serious problem, too -- and one that I'm guilty of! ...that is, if I'd ever gone to college. :-(
I am very much not encouraged by a "race to the bottom" when it comes to education. If calculus is too difficult for the student, then perhaps the student should not consider a career in programming. I say that without any malice whatsoever; I'm not sympathetic enough to be a counselor, and I wouldn't expect counseling courses to simply disregard the importance of counseling so that I could have a job in the field.
To bring all this back to a more practical argument: I am annoyed daily by the great and heaping piles of inefficiencies and bloats and bugs and weaknesses of software. I have to, on a regular basis, explain to clients that they should throw out their old computer and get a new one, so that they can continue to do what is, to them, exactly the same thing they were doing with their old one. That can be a rather challenging thing to explain to some people.
I find it difficult to believe that this ongoing pattern of abuse of resources is not at least partly related to a greater and greater ignorance of the fundamentals of programming.
I really don't see what connection calculus has with the vast majority of programming. Calculus, and algebraic manipulation in general, has next to no relationship with programming. I really don't see any reason why someone who has difficulty with calculus would have similar difficulties with programming; for all I know, they missed out on some fundamentals because they were sick in school, or they fell out with their maths teacher, or god knows what.
The only time I've ever used calculus in a program in 20+ years of programming is in physics simulation in some toy game apps; and that was just to derive some formulas that plugged in. They could have easily been solved today with some googling (other people probably solved the same problems) or questions on forums.
(FWIW, mathematics has always been my best and favourite subject in school, aptitude tests put me in 99th percentile, etc. IOW, I have no personal grudge against maths. I just see very little connection to programming outside niche areas, and even then they usually barely scrape the surface of the related mathematical area.)
PS: I think your specific bugbears are not related to mathematics either. Bugs: best approached with proper programming style like invariants and defensive programming, along with testing. The quality of software that people actually use can be measured from feedback, bug fix rates, etc. A bigger issue with bugs is usually economics; it's frequently more important to get things into people's hands quickly and cheaply than it is to have higher quality and compromise the other two. Bloat and sluggishness have two cures: measurement and big-O. I'd put both in engineering rather than maths. Understanding big-O, either explicitly or intuitively, is absolutely essential, though it's all blatantly obvious when you spend some time thinking about it.
The only thing special about calculus is that it is where practically all universities have decided to start teaching students to create real proofs with the level of formalism expected in other courses. This is likely due to the fact the world needed more engineers than programmers or mathematicians when this stuff got hashed out.
tl;dr: This promotes a view that those who reviewed SICP negatively did so because they were akin to people who wanted to learn how to drive rather than how their car works.
I read the 1st and last page (of 6, tl;dr etc.) reviews and I can't agree with this viewpoint. The negative reviews seem to be based on the structure (viz. haphazard) and tone (viz. boring) of the content rather than the level. That's not to say that I agree with these reviews; I'm just pointing out that the linked page seems inaccurate.
http://www.amazon.com/review/R403HR4VL71K8
http://www.ccs.neu.edu/racket/pubs/jfp2004-fffk.pdf