Won't this end in disaster considering the use of tail recursion in SICP versus Guido's flat out refusal to allow tail recursion optimization in Python?
What is important are the big ideas. For example, the course covers several paradigms: functional, oo and logic programming. The book uses Scheme for the first two and a language with very Scheme-like syntax for the last; Python is completely unsuitable for all but oop, and even there is too complex compared to Scheme.
I took this course in its old iteration last year, and it was a brilliant course, probably the single best course I've taken on any topic. That was partly because of the professor, who has retired, and partly because of the book and language. Now that only the book is the same, I suspect the course is very far from brilliant.
I should amend this by saying that the professor, who is actually from Google, is probably good--he created a set of AI projects used in a bunch of AI classes that are very good. However, the previous professor was particularly good as a professor--his research involved CS education. So far, he has been the best professor I've had, and I've had some very good ones.
> What is important are the big ideas.
Go back and read section 1.2 ("Procedures and the processes they generate") again. As far as its authors are concerned, this is one of the big ideas. Basic concepts of time and space complexity and recursive vs. iterative processes are so important that they appear as soon as the basics of Scheme have been introduced. It's a core theme of the book (Why is this n-queens program slow? How can we eliminate two extra stack saves in this register machine program?), and the main questions in chapter 5 that the evaluators in chapter 4 don't answer fully (but look closely at the CPS evaluator in section 4.3) are "how do procedures return values to their callers?" and the related "how can we write an evaluator that doesn't grow the stack when executing tail-recursive procedures?"
Ultimately, the beauty of SICP isn't in the paradigms covered but the understanding of how programs execute, and the beauty of Scheme is the simpleness of its control flow . It's far easier to a understand Scheme program than one written in Python, Haskell, Prolog, or any other high-level language. Do most people understand (modulo sophisticated optimizations) how the Python interpreter actually handles, say, comprehensions, iterators, generators, or its complex object-oriented features? Can a first-year student add these features by hand (forgetting completely about macros and first-class continuations) to an interpreter herself?
It amazes me that Berkeley professors don't want to teach Scheme (and worries me, as they're much cleverer than me). The whole magic of the language is that in the end there isn't any magic at all.