SICP (Python Version)(www-inst.eecs.berkeley.edu)
www-inst.eecs.berkeley.edu
SICP (Python Version)
http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/index.html
9 comments
I definitely agree with all that you've said. On the other hand, as someone who doesn't live in the US and could never afford that kind of education, I don't really care.
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.
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.
If you want to learn Python and you already know a programming language, you'll probably be best served by Python's official documentation: http://docs.python.org/
I'm not convinced it's a shame. As a freshmen, with only a small amount of previous programming experience, I didn't appreciate the beauty of abstraction or the elegance of the ideas presented.
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.
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.
As someone who took the Scheme version and is now teaching the Python version, there are without a doubt aspects of the course I miss. The old Scheme course just had a kind of elegance to 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]
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]
It seems to me that this version has much less to offer than the original. After reading only the table of contents and the first chapter, I feel as though it lacks many of the qualities that make the original such a classic in my mind.
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.
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.
I don't understand what justification there is for calling this "SICP for Python." I'm sure it's a fine Python textbook, but the table of contents bares little resemblance to SICP.
Nor does much of the content.
I took 6.001 at MIT in the 80's. Clearly, Abelson and Sussman did not choose Scheme because of it's popularity in industry, not even then. Nor did Barbara Liskov expect us to use CLU professionally, but that was the language for 6.170 back then (I think they teach it in Java now).
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.
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 also took 6.001 in the '80s and loved it, although the hardware was totally inadequate for Scheme. Code ran painfully slow. I adopted C and programmed in it for 12 years before coming back around to Scheme.
I just pushed some new Scheme code to my photoblog service, OurDoings, before I came here and saw this post.
I just pushed some new Scheme code to my photoblog service, OurDoings, before I came here and saw this post.
This is even better read using Crunchy (http://code.google.com/p/crunchy) running under Python 3. Crunchy styles the code, making it more pleasant to read, while inserting a Python interpreter whenever it detects some code, allowing to reproduce (or modify) the examples, instead of simply passively reading them.
I still haven't heard a good reason why universities are switching away from Scheme...
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.
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.
> 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.
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.
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.
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.
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.
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.
I would pay money to have this as a well-designed iBook.
Maybe I'll settle by downloading it for Instapaper.
Maybe I'll settle by downloading it for Instapaper.
UC Berkeley is also using the original SICP in its CS 9D class,Scheme for Programmers.
"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.
[1] http://www.cs.berkeley.edu/~bh/retire.html
[2] http://www.cs.berkeley.edu/~bh/proglang.html