
Why MIT switched from Scheme to Python - vorador
http://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python
======
trjordan
I think there's something else here, implicit in Sussman's comment, that's
important. MIT was founded on a philosophy of practicality, and everything
else is secondary. If you couple that with the belief that fundamental
computer science is the most efficient way to enhance practical software
engineering, Scheme was a wonderful choice. Java and C++ may have been more
directly practical to software engineers, but they are not good for the field
or people pushing the limits of the field - you spent too much time mucking
around with their paradigms and idiosyncrasies.

Python (and, frankly, a number of the scripting languages-turned-mainstream)
combines this clarity of computer science with a practicality that Scheme
never had. If you can convey 95% of the basic ideas in Python, and you can
also open the door to learning how to deal with 3rd party code, you'd be a
fool not to. It was never about programming purity anyway, so there's no
reason to mourn the passing of Scheme. It's progress.

~~~
jules
> If you can convey 95% of the basic ideas in Python

But you cannot.

Some of the ideas in SICP can nearly be conveyed in Python (like lexical
scoping, closures, data types, streams). You'll use built-in language features
in Python (classes, generators) instead of implementing the functionality. I
think that implementing these things is important if you want to really
understand them.

An example, cons, car and cdr from nothing at all:

    
    
        (define (cons a b) (lambda (f) (f a b)))
        (define (car p) (p (lambda (a b) a)))
        (define (cdr p) (p (lambda (a b) b)))
    

You can do this in Python in theory, but you can't throw this into a Python
course.

Other ideas, like interpreters, require a lot of effort. Try writing a
metacircular interpreter!

~~~
sharkbrainguy

      def cons(a, b):
          return lambda f: f(a, b)
    
      def car(p):
          return p(lambda a,b: a)
    
      def cdr(p):
          return p(lambda a,b: b)
    

As well as in theory you can do this in practice. It's about as elegant (hard
for me to judge as I have a strong pro-lisp bias).

Aside from lack of tail safety and performance issues with writing scheme-ish
code I don't see why you couldn't implement those things in Python. The main
difference is that typically in a real world situation you wouldn't because
there's a library or a language feature

~~~
jules
The problem is not that you can't do this in Python, but that this is out of
place in a Python course (you don't use linked lists in Python, for example).
SICP shows that you need only a very small number of primitives to get a full
programming language. You don't get this elegance with Python.

This may not be important if you teach programming to people who want use
programming languages, but it is important for people who want to advance the
state of the art in programming (i.e. CS students).

Maybe it's better if you teach Scheme in a seperate class class for CS
students.

~~~
scott_s
Keep in mind this is a freshmen level course. You don't have to - and
shouldn't - cram every important CS concept into an intro course.

~~~
jules
I agree. And this course probably is a lot better than the course I got (C++,
ugh). That may be the reason I'm biased...

------
lyriendel
I was a TA for 6.01 two years ago. 6.01 and 6.02 (Intro to EECS II, may have
replaced 6.001 and 6.002, but their purposes are fundamentally different, as
someone else mentioned earlier. They're now both introductions to a wide range
of CS topics--6.01 covers not just software engineering, but feedback and
control, circuits, and probability and planning; 6.02 covers things like
signal processing, digital logic, and networking. Good computer scientists
nowadays need to (or at least should) know so much more than how to write
good, clean, modular code. As the 6.01 FAQ says, they still teach software
abstraction ideas including functional programming, higher-order functions,
and object-oriented programming. They chose Python mostly because Python is
easily approachable. But most of 'modernizing' 6.001 isn't about moving from
scheme to Python--it's focusing on learning how to modularize/abstract and
model/analyze across a variety of different contexts (not just software, but
linear systems, circuits, and AI).

Also, 6.01 actually assumes that you have some programming experience already.
When I TAed, at least, we assumed working knowledge of basic Python from week
1 and told people to go read a Python tutorial/book if they didn't have such.
If you don't know how to program at all, you're supposed to take 6.00 first,
which is the real 'Introduction to Programming' course. Except that most
people skip it because they already know how to program or think they can
learn on their own (and because it's kind of seen as a remedial course, which
is especially unfortunate for people who really don't know how to program
already--6.01 is pretty harsh if you've never programmed before).

------
grinich
I'm a sophomore at MIT and took 6.01 last term.

I think a lot of people don't understand the goals of this course. 6.01 is not
meant to be a crash-course in writing code. (6.005, know as "java deathlab" is
for that.) Likewise, it's not designed to reveal the deep inner workings of
computers. Instead, it's mean to be an introduction in how to /think/ with
computers. It's conceptually more high-level, and often focuses on the "why"
rather than the "what." We learn how to approach problems and look at the best
ways to solve them using logic and code.

Python is visually clear, has great documentation, is well maintained, and has
an active community of developers. I don't understand the outrage in
switching. I didn't learn to drive in an obscure European sportscar; I learned
in my mom's minivan. Python is like my mom's minivan, but with better
documentation.

I don't think the caliber of CS grads coming out of MIT in the next few years
will change because they know Python, although it'd be an interesting thing to
look at.

#

Here's the course website, if you'd like to look closer:
<http://mit.edu/6.01/mercurial/spring09/www/index.html>

------
mjtokelly
"And why Python, then? Well, said Sussman, it probably just had a library
already implemented for the robotics interface, that was all."

I can confirm this is true. The Python Robotics module (Pyro) inspired MIT's
internal library, SoaR, which was developed at first by a highly motivated TA.

What does SoaR stand for? Snakes on a Robot, of course.

~~~
tlb
Pyro is great. We don't use it because I started our robotics code base in
2001, but if I were starting from scratch I'd use many pieces of it.

I believe the main reason why robotics has progressed so slowly in the last 30
years is that getting the damn hardware and firmware working together takes
90% of the available time and students barely get beyond that. So libraries
that abstract away most of that and enable plug-in real-time control modules
are going to give the field a huge kick in the pants.

------
alecco
Blog spam. It is a huge quote from this:

[http://wingolog.org/archives/2009/03/24/international-
lisp-c...](http://wingolog.org/archives/2009/03/24/international-lisp-
conference-day-two)

~~~
gojomo
Pulling a meaningful, discretely discussable quote from another place isn't
necessarily 'blog spam'.

Sussman's rationale for the change in 6.001's focus and language is more
interesting to me than anything else in the 'international lisp conference --
day 2' post, and is hidden near the bottom of that post. So, the pull quote
blog item adds finding/filtering value for me, which is the opposite of spam.
Neither the blogger nor submitter deserves the implication they are a spammer.

~~~
scott_s
Thanks - I was going to point out the same thing. The linked blog has no ads,
so I don't think he's going to gain much from hits.

~~~
alecco
Tomato, potato.

------
wensing
Are they still going to teach Scheme in any other course(s)? Why not teach
both?

I had the privilege of taking an SICP-based course at the U(C). The brain-
stretching is critical, isn't it? Yes, there's a lot of head-slamming that
goes into modern development, but that's not really the same thing.

~~~
jerf
Python may not be a scheme, but it does have what they used to call functional
programming, low-grade continuations with the generators, and some other stuff
like that.

Python may not stuff its academic credentials in your face, but I think it has
one of the better balances between what you _can_ use it to teach, and what
you _must_ teach to use it. (Referencing the common and IMHO justified
complaint that the simplest possible Java program requires rather a lot of
stuff to be taught before you fully comprehend it.)

Teach Scheme later... or perhaps, fully distinguish between academic and
practical by starting with Python to get you going then transitioning to an ML
or Haskell later. (That approach has a lot of appeal to me personally, and has
the benefit of the student coming out with at least _one_ useful-in-the-
industry language (Python) without compromising academic utility very much.)

~~~
silentbicycle
Python has some issues that can really interfere with doing Scheme-style FP in
in it (no tail-call optimization, single-expression-only lambdas,
closure/scope problems, general hostility from Guido), but IMHO it's a great
general-purpose language, and well suited to teaching, particularly for
introducing higher-order functions.

Lua has much more Scheme influence than Python does (while being otherwise
pretty similar). Its design assumes proficiency with C, however, so, while
very practical, it's probably not as good a language for people new to
programming.

~~~
jerf
Yeah, that's why I called it "what they used to call functional programming".
Functions are first-class values and closures are easy to get at. (Some people
quibble with the exact implementation, but they are definitely there. Such
people will be happier with Python 3.0, but still not entirely satisfied.)
This is what "functional programming" used to mean.

Now it means having immutable values, tail recursion, easy lambdas, powerful
type systems, and so on. There's a clear historical progression from past to
present, but there's still been changes in what the term means over time which
means that different people mean different things by "functional programming"
if they don't clarify.

~~~
silentbicycle
Agreed. I originally said "lisp-style", but changed it to "scheme-style" for
just that reason.

------
mitko
Hi, I am MIT student in CS and I took 6.001 (the new course is called 6.01).
When I asked the instructor why we are using some language that has almost no
practical use, they told me that the reasons are: \- it teaches the concepts
of the class well \- after it one can learn any programming language very
easily.

I believe both of these to be true. From my point of view the new 6.01
sacrifises depth for breadth. This is part of much bigger change of the
ciriculum in MIT. That's why I hurried to take all nice classes before they
get destroyed.

P.S. I didn't know python untill 2 weeks ago. But I learned in need very fast
- definitely having background in different programming languages helps a lot.

~~~
scott_s
Then you can also take comfort in the fact that Python has enormous practical
use.

------
DavidSJ
After his explanation, I asked Sussman why, if that's the world we now live
in, it was a bad choice. He responded: "I didn't say it was bad. I said it
would make you sad."

------
asciilifeform
It it just me who is seeing a cowardly surrender to cultural decay here? From
the renowned Sussman, no less.

The glorious MIT of the 1980s and prior appears to be dead. Erased, in fact,
without a trace. Consider the following:

<http://mitpress.mit.edu/catalog/browse/browse.asp?btype=2>

These are the latest releases from MIT press. Among them you will find nothing
remotely like SICP, but plenty of postmodernist/related pablum.

 _"You have to do basic science on your libraries to see how they work, trying
out different inputs and seeing how the code reacts."_ Is this not an
atrocity, to be fought to the last bullet? Is this not an argument for
declaring all existing software obsolete and starting from scratch? Why are we
- even luminaries like Sussman - so willing to give up on the future without a
fight?

As argued in some of PG's essays, in order for creativity to bear fruit it is
not enough for a given individual to possess a creative mind. The culture has
to be hospitable to creativity. And there are processes which come close to
stamping out creativity without any overt or deliberate suppression involved.
Specifically, a transition to a medium where one cannot get reliable,
understandable "small parts" having predictable behavior.

Take note: <http://xkcd.com/298/>

Programmers have indeed created a universe where "science doesn't work."
Learning where the permanent bugs and workarounds are inside a phonebook-
length API teaches you _nothing_. It is anti-knowledge. Where your mind could
have instead held something lastingly useful or truly beautiful, there is now
garbage.

There is no longer a "what you see is all there is" Commodore 64 for kids to
play with:

<http://www.loper-os.org/?p=16>

No one is working on, or sees the need for a replacement. This is just as
well, considering as one would have to start from bare silicon - and avoid the
use of design tools built on the decaying crud of the past. Only a raving
lunatic would dare contemplate it...

Outside of programming: Linus Pauling developed an interest in chemistry by
experimenting incessantly throughout his childhood. Today, he would have been
imprisoned:

[http://memepunks.blogspot.com/2006/06/americas-war-on-
scienc...](http://memepunks.blogspot.com/2006/06/americas-war-on-science.html)

The new generation will have no Linus Pauling, unless the Third World - where
one might still purchase a beaker without a license - supplies us with one.
Likewise, we will see very few truly creative programmers. What creativity can
there be when your medium is shit mixed with sawdust?

~~~
danbmil99
"You have to do basic science on your libraries to see how they work, trying
out different inputs and seeing how the code reacts." Is this not an atrocity,
to be fought to the last bullet?"

I think it's an acceptance of reality. There is a phase change when systems
become too complex for a single human to ever understand them in their
entirety. Dealing with systems at that level is a different beast than dealing
with simpler systems where "what you see is all there is".

"What creativity can there be when your medium is shit mixed with sawdust?"

The same sort of creativity artists possess, who work with media that are
idiosyncratic. It's a different mindset. I see the reddit-gen programmers talk
about things on a completely meta-level. To them, MySql is the hardware. Is it
a bad thing? Not necessarily. Some of them hopefully will dig down the stack
and be the low-level heroes. But that should (and probably can) only be a
small percentage.

Now I guess one could argue that those sorts of heroes are what MIT is
supposed to produce, but as has been mentioned, this course is _not_ just for
CS students. So the real question is, can the CS heroes of tomorrow survive an
introductory course in Python? Well, consider that they have probably been
modding games since 10, hacking PhP at 12, realizing at 14 they need to learn
a 'real' language (C#, Ruby, Python), by 15 I bet they've abstracted out the
fact that languages are not all that important; they're just the tip of the
iceberg of complexity.

So yes, I think they will survive.

~~~
asciilifeform
>I think it's an acceptance of reality.

All of technological progress consists of refusing to roll over and "accept
reality" - instead, attacking it and modifying it to suit our needs.

>There is a phase change when systems become too complex for a single human to
ever understand them in their entirety.

This is how innovation dies. The disease is preventable:

<http://naggum.no/erik/complexity.html>

> To them, MySql is the hardware. Is it a bad thing?

Yes! It is. A programmer's finite mental capacity for dealing with complexity
is consumed by an ever-greater load of accidental complexity - inconsistencies
in the medium learning about which teaches you _nothing_. They are holes in
reality. The thing that made modern technology possible is that physics,
chemistry, etc. do not have "bugs." A correctly set up experiment will yield
the same results when done a week from now, in Australia, etc. And in the end,
there are unifying principles governing it, which will explain everything that
happened in a way that teaches you something permanent. A medium with "holes",
like a buggy programming system, is a universe where "science does not work":

<http://xkcd.com/298/>

> Some of them hopefully will dig down the stack

Wading in sewage.

> languages are not all that important

This statement is true when the languages are all equally crippled - as they
increasingly are, through their reliance on an ever-sinking foundation of
35-year-old rotting OS.

~~~
danbmil99
I believe I categorically disagree with every point you make. You are pissing
in the wind if you think you can treat a system with 100M LOC the same way you
wrote assembly on a 6502. They are different beasts, with totally different
emergent properties. It's like claiming that you can understand the weather if
you just stick to thinking about individual molecules.

[edit:] I believe the xkcd strip can be read two ways. Unknowable complexity
equals magic (a riff on Arthur C Clarke). I strongly believe that exactly
what's been wrong about software is our clinging to the idea that it is
reducible and manageable. We don't think that way when we work in the physical
world; we do rely on science, but it's empirical science, with statistically
useful models at appropriate levels of abstraction. We don't rely on quantum
mechanics to build bridges.

~~~
asciilifeform
> you are pissing in the wind if you think you can treat a system with 100M
> LOC the same way you wrote assembly on a 6502

I would be, if I actually believed that it is possible given current
technology. However, I believe that the problem is technological rather than
fundamental, and that we can arrive at a solution. Let me give you an example
of a problem that was once thought to be fundamental and inescapable yet
ceased to be viewed as such. Before the advent of high-quality structural
steel, no building (save a pyramid) could exceed five stories or so in height.
Towards the end of the 19th century, metallurgy advanced, and the limit
vanished. I believe that we are facing a similar situation with knowledge. The
conventional wisdom is that the era of "encyclopedic intellects" (and now,
human-comprehensible software) is gone forever due to the brain's limited
capacity for handling complexity. Yet I believe that the computer _could_ do
for mental power what steam engines did for muscle power. I am not alone in
this belief - here are some pointers to recommended reading, by notables such
as Doug Engelbart:

<http://en.wikipedia.org/wiki/Intelligence_amplification>

Additionally: why do you assume that any system built to date necessarily
_must_ contain 100M LOC? Does this not in itself suggest that we are doing
something wrong?

> clinging to the idea that it is reducible and manageable

All of technological civilization rests on the assumption that the universe is
ultimately "reducible" to knowable facts and "manageable" in the sense of
being amenable to manipulation (or at least, understanding). The alternative
is the capricious and anthropomorphic universe imagined by primitive tribes,
run according to the whim of the gods rather than physical law.

> We don't rely on quantum mechanics to build bridges

I must disagree here. QM is entirely relevant to the science of material
strength, which is ultimately a branch of metallurgy - arguably a discipline
of applied chemistry. In any legitimate science, there really are "turtles all
the way down." And when there is a discontinuity in the hierarchy of
understanding - say, the situation in physics with the need to reconcile
general relativity and QM - it is viewed as a situation to be urgently dealt
with, rather than a dismal fate to accept and live with forever.

A computer, unlike the planet's atmosphere, is a fully deterministic system.
It is an epic surrender to stupidity if we start treating programming the way
we treat weather prediction - as something that is not actually expected to
reliably _work_ in any reasonable sense of the word, or to obey any solid
mathematical principles. It is a disaster, to be fought.

~~~
danbmil99
I think we're talking past each other, though there is still a fundamental
disagreement in principle. Of course I believe that science 'works', in the
sense that in theory, everything should be reducible to a lower level
description. High-level source code reduces to machine code; weather reduces
to quantum mechanics. However, there's a critical decision about what level
you choose to work at when you attack a problem. While you may know that QM
has something to do with why certain steel alloys are strong and light, when
you build a bridge or a building you don't work at the QM level.

In the practical world of software development today, we do indeed have tens
of millions of lines of code 'under' the application level most of the time.
Even on Linux, where every one of those lines of code is theoretically
accessible as source, the practical fact is nobody has the resources to read,
comprehend, and manage all of that code during the lifetime of a typical
project. Therefore, you are necessarily in a position where you have to deal
with most of that codebase as black boxes, which have a statistical likelihood
of doing what they are intended to do. You have to program defensively, hoping
for the best but assuming the worst. You have to rely on your pattern
recognition skills and your intuition to guide you. You have to treat the
chaotic complexity you sit on top of like a surfer riding a wave. You cannot
afford to take a fully reductionist approach. It's just not possible anymore,
full stop.

The exception to this would be a small, embedded system with a minimal
operating core and limited memory. But wait -- that system today is almost
sure to be networked up to the bigger, chaotic systems that populate the
metaverse. So again, at the level of communications, you have to treat the
components you communicate with as black boxes.

If you disagree, give me a feasible scenario in which you could in fact take
control of the situation in a reductionist fashion. I propose that any such
scenario is a toy problem, that will not scale to real-world deployment.

The cat is already out of the bag.

~~~
asciilifeform
I don't disagree with the necessity for fundamental elements ("black boxes")
on top of which to build. My only complaint is with the universally shoddy
state of these black boxes. Specifically:

<http://www.loper-os.org/?p=37>

The modern computer is the first time mankind has built a system which is
_actually capable_ of perfection. You are more likely to have a spontaneous
heart attack and die at any given moment than the CPU is to perform a
multiplication incorrectly. All of the "hairiness" which your computer's
behavior exhibits is purely a result of programmer stupidity. It is
theoretically possible for the entire stack to work exactly as expected, and
for each element to seem as inevitable and obvious-in-retrospect as Maxwell's
equations.

It is possible to build a system where the black boxes aren't fully black and
can be forced to state their _actual_ function on a whim. It is possible to
expose the entire state of the machine to programmer manipulation and
comprehension in real time:

[http://groups.google.com/group/comp.lang.lisp/msg/b2c0190dc3...](http://groups.google.com/group/comp.lang.lisp/msg/b2c0190dc30c3e5f?hl=en&pli=1)

[http://www.sts.tu-harburg.de/~r.f.moeller/symbolics-
info/dev...](http://www.sts.tu-harburg.de/~r.f.moeller/symbolics-
info/development-environment/index.html)

>The cat is already out of the bag.

The Lisp Machines existed, and were capable of everything modern, "hairy"
systems are capable of, plus much more. You cannot un-create them. They are
proof that the entire software-engineering universe is currently "smoking
crack" - and I sincerely wish that it would stop doing so.

~~~
danbmil99
we don't need lisp to know the state of the machine -- in the Linux case, we
have source code. We can _theoretically_ debug everyone else's code and know
exactly what is going on.

"It is theoretically possible for the entire stack to work exactly as
expected, and for each element to seem as inevitable and obvious-in-retrospect
as Maxwell's equations."

Yes, and it is theoretically possible according to the laws of physics for
broken glasses to spontaneously reassemble. But they don't.

This is basically an issue of entropy.

~~~
asciilifeform
Have you ever actually _used_ a Lisp Machine? There is an emulator available
(ask around.) All of these things were actually possible there - not merely
theoretically.

~~~
danbmil99
Maybe I'm not making myself clear. I realize you can in principle debug
everything, know the state of the machine completely, etc. What I am trying to
point out is that it is too much information to handle at that level of
detail. It doesn't matter if it's written in Lisp or Swahili. And the fact
remains that even if you convinced 90% of the next generation of programmers
to use Lisp, you still have 50 years of legacy code lying around in other
langauges. These are practical facts that can't be washed away with a new (or
old) programming paradigm.

------
screwperman
I read SICP when I was 14; this was a couple of years after I came across some
pg/Lisp stuff. It would be absurd if MIT CS students remain ignorant of 6.001
given their institute's really hardcore hacker culture. Hence, I fail to see
what this entire fuss is all about.

------
time_management
I wonder, if the switch had been made now, it they would have switched to
Clojure instead of Python. It's a lot closer to Scheme, and its connection to
the JVM gives it a lot of practical power. Does anyone have any thoughts on
this?

~~~
tlb
People often say that Java has great libraries, but is it true? AWT is crufty
and ugly. Maybe there are impressive XML parsers (Xerxes is 188,000 lines of
Java!), but I don't want those. Numerical libraries seem bad. So what is the
library that might convince me to use Java for something?

~~~
herdrick
No, they aren't very good. I think the problem is cultural. Programming Java
gets you comfortable with extreme verbosity and tons of structure so its
libraries end up like this:
[http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server...](http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html?rel=html)
(In extreme cases.)

Lucene was mentioned earlier - it, at least, is very good.

I have the same impression about the numerical computation and machine
learning libs too.

~~~
time_management
There's a lot of "enterprise" crap in the Java libraries: extreme verbosity is
the most notable problem. Object-orientation is also just the wrong metaphor
for many problems. Finally, camelCaps are uglyAsFuckAndNotVeryReadable.

However, the JVM libraries are well-supported and generally can be trusted to
work. For a lot of the wheels I'd rather not reimplement, they're quite
useful. I don't think that the Clojure of 2020 will be as reliant on Java, but
for now, the JVM libraries are very useful.

