Why MIT switched from Scheme to Python (2009)

Isn't this just part of the broader trend of CS departments switching away from teaching computer science to teaching computer engineering, which in turn is part of the more general trend of colleges becoming more vocational?

LISP dialects like Scheme are excellent for teaching pure computer science because they are the closest thing to executing lambda calculus expressions. Whereas Python is excellent for teaching applied computer engineering, because it's essentially executable pseudocode for imperative languages, and imperative languages are the most common language a computer engineer encounters in the real world.

When this kind of switch was happening in CS departments, as a graduate student I was part of a "movement" that advocated for switching away from things like Scheme to Python for introductory classes in my elite CS institution. (We focused on other things as well such as more interdisciplinary research, which was where I was more passionate, but that's a separate matter.)

My reasoning at the time in this order was:

1. Widely used tools and practices offer a flywheel of usefulness that can help motivate undergrads to learn about computation. Once you learn Scheme, well now you've learned Scheme. But at the time if you had learned Python you could then use something like Python's system and socket APIs to play around with the lab or personal Linux systems. On the web side, there was web.py or Flask (haha this was the late 2000s/early 2010s) to motivate yourself to keep going. The student could spend their summer building apps and tools so that they appreciate computation for more than just its "aesthetic" beauty.

This was a time when CS wasn't all that prestigious on its own and salaries weren't as high as they are now, so many folks who banged their head against Scheme or MMIX or LC3 would just churn to the EE or MechE departments.

2. As a grad student it was almost trivial to set an exam paper that could weed out most of the class. This was especially trivial at the introductory class level where Scheme would be taught. If the concern was rigor it was very simple to maintain the rigor in other ways.

3. For better or for worse many undergrads had no intent of going to grad school, and many of the undergrads taking our classes weren't even students of computer science. They were electrical engineers or industrial engineers who wanted to learn enough programming to automate things in their field but were more interested in their actual areas of concentration.

In the years since my thinking around this evolved, but I still share the same conviction I did then. Probably moreso given the sheer ubiquity of Python now.

I think the solution is to have, as is the case in math/physics, an honors intro CS sequence compared to the regular intro CS class. The latter would be the recommendation for all non-CS majors, and the former would be for CS majors. I've always thought that those who are focusing on more vocational training should not be in what is called the CS program, maybe there are other majors called "software development" or "data science" or the like. Undeniably most prospective CS students are not aiming to go into academia, but we shouldn't adapt to this majority and then leave behind those who do want to do more academic things.

My background is in physics, where this sort of dual-track curriculum is well-established, and the physics taught to physics majors is very different from that taught to engineers. Unfortunately the difference is often boiled down to rigor or difficulty (and this will be reinforced if it's physics professors that have to teach both of the tracks), but in reality it is a value-neutral split which is based on pragmatism. CS should have one too.

We did end up making this switch later on due to growing class sizes anyway. That certainly helps focusing the class. We ended up focusing on computation more for the CS sequence and on the nuts and bolts of getting a program working for the non-CS sequeunce.

But my rationale for moving to Python still stands. In fact, I know several brilliant ML researchers who write code that would never come close to making it to production. The things we optimize for are different. Production code in a tech company needs to be readable, maintainable, explainable, and scalable. An ML researcher's code needs to support their research. These different perspectives are still why I think focusing on a wider appeal language like Python over something like Scheme still makes sense.

FWIW our CS program mandated a programming languages class and the first third of the class was taught in Scheme.