According to an article on The Snowtide Blog, MIT has decided to teach beginning CS classes in Python rather than Scheme. (Thanks to procoders.net for the link.) The article paraphrases remarks by Gerdald Sussman at the announcement.The main rationale was that the world is more complicated now than when the course was designed and SICP was written. Now programmers spend more time researching libraries than writing everything from scratch.
Here’s something I expected Sussman to say though apparently he did not: you can use Python as a functional language if you like, you just don’t have to. I don’t know why more people don’t emphasize this. Python is not a functional language, but Python does make it easy to declare functions on the fly, pass functions as arguments, etc. You’re free to write Scheme-like programs in Python if you want to, but you’re also free to use other styles when they are more appropriate.
7 thoughts on “MIT replaces Scheme with Python”
well I can understand the motivation but nevertheless it’s somewhat sad.
BTW: I don’t know python but you only mentioned creating and passing functions as an argument but to do serious FP you need functions as a result, closures, etc.
I believe they changed to Python some years ago. The article merely states the reason and is not an indicator of when it happened.
They phased in the Python class before they phased out the old Scheme-bearing 6.001 (whose last class was, I believe, last Spring).
My impression is that, in person, Sussman is very open to Python-as-a-language, and encourages people to use it in a kind of Scheme-lite sort of way (although, without tail-call optimization and continuations, there’s a lot you can’t do in Python as easily as in Scheme). Sussman’s more advanced symbolic programming course is still taught in Scheme, although some of the class projects last year were done in Python.
@carsten: functions are 1st-class objects in Python, and what you ask for is available, i.e., creating, passing,returning of function objects (both named and anonymous, i.e., lambda, but for the latter, there are no blocks, just a single expression), statically-nested functions, inner functions, closures, currying/partial function application, as well as ways to map and filter arrays (Python lists) using map()/filter() or list comprehensions or generator expressions. Python functions can also be coroutines and generators where functions can be “paused,” yield some intemediate result, then resumed with an iterative next() call to retrieve the next result. Similarly, you can also pass in values to the generator as well as exceptions. Of course, Python functions also support general features such as default arguments and variable arguments.
In my opinion, writing flexible functional code in Python is not like writing in Scheme. I would say Python has functional features, whereas Scheme encourages functional use by clearly and easily allowing scope control. When actually metaprogramming and functionally programming in Python, Perl and Ruby, there are gotchas in the nooks and crannies of those languages that Scheme’s clean design avoids.
For example I recently wrote a routine that did a hex dump on my system and was happy to have Python’s functional features:
def debug_dump_mem(adr, len):
if not debug_test: return
f = lambda a: ((a = adr+len) and “xx”) or (“%02x” % dut.ReadRegister(a))
line_adrs = range(adr & ~0xf, adr + len, 0x10)
for line_adr in line_adrs:
byte_adrs = range(line_adr, line_adr + 0x10)
print “%04x: ” % line_adr, ‘ ‘.join(map(f, byte_adrs))
That doesn’t hold a candle to this snippet from Essentials of Programming Languages IMHO:
(lambda (texp tenv)
((loop (lambda (texp)
(cases type-exp texp
(tid-type-exp (id) (apply-tenv-typedef tenv id))
(int-type-exp () (atomic-type ‘int))
(bool-type-exp () (atomic-type ‘bool))
(proc-type-exp (arg-texps result-texp)
(map loop arg-texps)
My two cents really…
However it is quite cool that Structure and Interpretation of Computer Programs lives on for free as download!
Thanks for the post.
It’s worth taking a look at Peter Norvig’s article “Python For Lisp Programmers“.