SICP (Python Version)
www-inst.eecs.berkeley.edu
www-inst.eecs.berkeley.edu
"In an ironic development, while the Berkeley CS faculty pretty clearly regard the Python-based course as the future of 61A for Berkeley CS students, both the UC Online people and the team at Stanford developing technology for massive online courses are excited about adapting 61AS to their formats. So, down the road, it may be that everyone except Berkeley students can study SICP."
An also[2]:
"You can learn to program in any language. But it’s not just an accident that the authors of SICP chose Scheme as their teaching language. The big ideas in the book — the ones that alumni in the real world tell us they’re using in their work — express themselves best in Scheme. Indeed, saying it that way puts the matter backward. Gerry Sussman (with Guy Steele) invented Scheme before he turned (with Hal Abelson) to expressing the ideas behind Scheme in a course. SICP is Scheme, in tutorial form."
BTW, if you have some free time and want to learn Lisp, do yourself a favour and go watch the old Scheme-based lectures on Berkeley's webcast; they're awesome.
PS. I do most of my professional work in Python.
I am actually grateful that I now have access to what looks like a great Python book in addition to the existing SICP book and videos.
I can't wait to read the Distributed and Parallel Computing chapter.
A few years later, though, and I understand why it's a revered text. While there is something to be said for learning the fundamentals of computer science before bad habits are formed, it seems that the real messages are often lost in the hands of first-time CS students (which is probably over half the Berkeley freshmen EECS class).
That said, I haven't been through the alternative and I can't vouch for it.
We are still striving to teach the same material, just in a different language. This class is not at all a class about Python, just as the old course was not a class about Scheme. The course content is almost the same: functional programming, data abstraction and data structures, OOP, interpreters, parallel and distributed computing, declarative programming.
We have unfortunately had to sacrifice some great aspects of the original class, eg. the metacircular evaluator. The hope is that in exchange we have a more natural OOP system, better support for parallel and network computing packages, and much more modern implementations of distributed computing.
[disclaimer: these are my own opinions, I do not speak for the department]
Most of these qualities have nothing to do with Lisp. SICP had a tendency to take things slow. The presentation of the material reflected how programs are actually structured -- the text incrementally built on itself much in the same way that abstractions are built on other abstractions.
While reading through the first chapter of the Python version, I felt as though I was being bombarded with tidbit after tidbit without the richness of explanation featured in the original.
One thing that's missing is metalinguistic abstraction. This is something that's comparatively easy to do in Lisp, so it's understandable that it's been left out of the Python version. Unfortunately, that chapter of SICP is often an eye-opener for even experienced programmers.
Parallel and distributed processing are certainly welcome topics, and will probably become necessary (if they haven't already) as we continue moving into the Information Age.
Overall, however, I didn't get the feeling that this work keeps the same spirit as SICP. I think an almost one-to-one code translation of the first three chapters would have been better.
So this movement to "port" SICP to Python or whatever other modern language seems to misunderstand the purpose of the book.
Come back in another 25 years and let's talk about which version of the book is still considered classic.
I just pushed some new Scheme code to my photoblog service, OurDoings, before I came here and saw this post.
I'm not one to claim "we must follow the old ways" just for the hell of it. I can understand the desire to look out at the world of programming languages (which is much larger today than it was when Scheme was invented), but there was a reason to pick Scheme for the original: it's simple.
Python, with its "batteries included" philosophy is a poor choice because it misses the original intent. With Scheme, you have to invent everything. With Python, you just have to look up the documentation.
Honestly, I can't for the life of me understand why they didn't replace Scheme with Lua.
For many new programmers, a "batteries included" approach is potentially much better. Once you've learned a little Python, you can read the docs for SimpleHTTPServer and make an online application. I can't imagine how mindblowing that would've been for me as a kid: "you mean I can write this little program and now I have a webserver on the Internet just like Google?"
I get where you're coming from. At some point, any would-be professional programmer needs to write a linked list, a binary tree, and a quicksort; not that she'll actually end up using her implementation, but for the sheer experience of understanding what's going on at that level. But I can certainly see the charms of teaching the abstracted versions first so that higher-level concepts are approachable earlier.
Your point doesn't hold.
With Racket, which is the recommended scheme, you don't have to invent everything - you just have to look up the documentation. And if you think you won't use Racket, or use #lang htdp or something in Racket; these are artificial restrictions and students can very well be asked(like you are asking not to use batteries with Racket)to respect them while coding in Python.
There are other reasons to prefer Scheme over Python, but this isn't one.
Maybe I'll settle by downloading it for Instapaper.