When I studied SICP I used XLisp under DOS (no tail recursion, 640k). OTOH Python's default recursion limit of 1000 is even more restrictive than that.
The question I had is how are they going to code a metacircular interpreter? Apparently they make a Scheme interpreter instead.
I'm currently reading SICP (the original one). Even though it's LISP instead of Python, the syllabus seems to be very implementation-agnostic. Tail recursion optimization is nice and comes in handy, but I don't think it matters much in the choice of a language to teach this course.
Focus is naturally put on how a language looks on paper, more than how it executes on the machine.
I remember the text--and the old course--actually spent a good bit of time talking about proper tail calls and "iteration" vs "recursion". We talked about how the code behaves differently--e.g. space usage--and about how to identify the two types.
Also, it's the Structure and Interpretation of Computer Programs; naturally, the first bit talks about how programs look (structure), but the second bit (mainly chapters 4 and 5, if I remember correctly) talks about exactly that: how to execute code on the machine. The last chapter, in fact, introduces a register-based language not unlike assembly.
It's the self-paced, Scheme-based version of the course. The website is currently for last semester; I have some friends working on it and they promise the next iteration (should be up soon) is going to be really awesome. I believe them.
Also, since it's a self-paced course, it's probably a much better option if you want to work along on your own in your free time. I think some other institutions might be using the materials from this class as well, but am not sure about that.
Here are the rather insightful thoughts about using Scheme vs Python for this course from its old professor (who was really awesome): http://www.cs.berkeley.edu/~bh/proglang.html
Gah, stuff like this just tends to make me upset. SICP is probably still, bar none, the best text I have ever read. In any subject. Now, I'm biased towards computing and I'm sure that there are amazing texts in every field, but I would put this up against any book you can find.
The book touches so many fields in computing and does it in a profound, deep, yet entertaining way. Part of its ability to do so is its use of scheme, a language that doesn't give you a whole lot in conventional terms, but which also puts very few restrictions on your ability to build those things up, so you can get an understanding of them as you create them. Polymorphic method dispatch can seem magical if it has always "just worked" for you in Java, but when the text discusses a system for implementing this (several systems in fact) suddenly it all clicks, and the magic you use every day is a little bit more comprehensible.
And so I feel like attempts to teach SICP but in whatever the more practical language of the day is are misguided, and ultimately a little bit of a cop-out. Before you read the next few sentences let me preface them by saying that I have respect for everyone involved with these decisions even if I don't agree with them, and I don't want to come off as supposing malicious motives on their part.
But the overwhelming feeling I get from reading about these initiatives is that people have looked at SICP and said "Wow that is really a great book, shame about how it uses this fringe language. I know, I'll use language-x which is much more practical, and if there are areas in the text that language-x can't really handle, I'll limit the size of the recursion, or not use higher-order functions as much, etc, etc". And that misses the point. If you want to use language-x then you should probably step back and write a text using language-x that is just as amazing as SICP, and that really utilizes the strength of language-x in the same way SICP utilizes the strengths of scheme. But of course that is really, really hard work and so no one does it. Instead we get initiatives like this that dispense with the magic of using scheme and tail-recursion and lambda, and shoe-horn it into lisp, while also constraining Python to a weird lispy style doing basic things like defining your own functional binary search on a list, which is entirely against the whole reason you use python which is BATTERIES INCLUDED.
And thus you end up with a lazy compromise that doesn't really do justice to either the tremendous original material, or the strengths of a current language. I really think that before you decide to use SICP but with a "modern" language you should ask yourself why you are using SICP and not the amazing course material you have put together yourself to really leverage the strengths of language-x in a way that also teaches computer science. And if your answer is "Because that would be a lot of hard work, and I can just have students do list recursion in python, on small lists, and without doing too much higher-order stuff" then I submit you should abandon your plan and head back to the drawing board, with better goals, and higher standards.
Scheme wasn't shelved because it was a "fringe" language. In fact, Prof. Hilfinger the one who brought it to Berkeley in 1980, and that class 61A is the first course all CS majors take. Brian Harvey taught the class for ever, and published his own textbook "Simply Scheme."
MIT is doing something similar, with the support of the authors.
The same material is being taught, just in a different language.
MIT is not doing something similar; they are teaching different material in Python, following a different book. This is unpopular with the very best students, but even so only the ones who have ever heard of Scheme and SICP. But the introductory computer science course teaches state machines, a bit of recursion, and also a bit of circuits and the like. Nothing nearly as cool as writing your own compiler, however.
When I took CS61A over 8 years ago with Prof. Hilfinger, one of the revelations was how few primitives you need to make a powerful language. Using define, cons, cond, and a couple other functions (but no loops and no assignment), you can write an evaluator for Scheme that can interpret any other Scheme program (excluding I/O, strings). I learned how powerful a first-class function is from that class.
Python has a wealth of syntax and data structures that make it great for real programs but is perhaps not as good at building abstractions from the ground up.
I wonder how much the TAs had influence on the Labs, or the Instructor is trying really hard to relate with today's students.
From Lab 4 [0]:
Exercise 2: Data Herp Derping
The same lab -- possibly others -- has mixed whitespace usage (ex. str_rat method), which may be worrisome for introducing students to languages that hinge upon proper whitespace. The examples will work, as expected, but beginners may be confused by usage of or burdened by not understanding the implications of using 4 spaces here, 6 spaces there, etc.
scheme/lisp was choose by Sussman and Abelson because it does not get in the way to explain SICP.
Python can be a problem and get in the way; scheme was beautiful because it's so simple that all that rest to understand is the really big ideas described in SICP.
There are 61A videos on ITunes U but it's hard to tell if they are from the Python version of the course? Anyone know if there are videos of the lectures kicking about from past years of the Python version?
A little off topic, but reading from week one include a Unix/Emacs tutorial. I wish they would stop defining "cat" as a command to "displays the content of specified files". This trend in the "Unix teaching" community is leading to a lot of terrible practice (Useless use of Cat) in the industry.
I die a little every time I see
$ cat file | grep word
Correct definition of 'cat' -- a tool to concatenate one or more files sequentially into a single output stream. E.g., cat file1 file2 file3 >output-file
what is wrong with... -- "grep word file" takes fewer keys to type and uses fewer resources (important on a heavily loaded server with tons of processes which may well prove compromised and you're trying to peruse the logs for evidence. Been there, done that, got the t-shirt, and donated it to the local shelter).
People nag me about cat'ing stuff to grep, and I explain that it's just easier to edit the pattern when it is the last argument to the command. Also it of course fits better in the toolchain when I need to replace the input or the grep with something else.
Oh, I see, just give them trivially small data sets: http://www-inst.eecs.berkeley.edu/~cs61a/sp12/labs/lab8/lab8...