Why MIT switched from Scheme to Python (2009)

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.

On the contrary, I suspect that such a person is likely to be better suited to build software in either of the latter two.

I also suspect that Python is not a particularly good first language for someone who aims for a professional career building software.

The point is that python's syntax reads a lot more plainly and logically for learning than something like Java.

Formal reasoning about imperative programs in terms of their (e.g. axiomatic) semantics is only in a grad-level course, and the programs you can reason about are really, really limited compared to the functional ones. (The last time I TA'd the FP class, one of the homeworks involved proving a simple compiler correct. When I took the grad course, I think the most complicated program we proved correct was selection sort.)

I think "reasoning about programs" is more computer-science than "writing programs," and choosing an imperative language signals that you're not emphasizing the former.

And honestly you could go your whole career without touching it, maybe only for the naming of an anonymous function.

Boolean logic, graphs, FSMs, set theory, mathematical proofs, pretty much all user here or there. Lambda calculus? Unless you're one of those Haskell fans, meh.

Ultimately, it doesn't matter. It's your first language, not your last.

The problem likely has always been the companies / HR rather than the students.

> I also suspect that Python is not a particularly good first language for someone who aims for a professional career building software.

It's not a particularly bad one either, certainly better than Java.

IIRC a secondary benefit is that it allows overlap between some of the basic CS, and the CS/CE courses for non CS track students

They won't be. But students don't understand that, they want to learn marketable skills and are 18 years old. They haven't figured out that if your skills transcend language choice you will be more marketable even if it means you have to spend a few weeks learning a new language for a new job. They lack maturity, which isn't surprising given their age and experience, and so they complain.

What I think you're really lamenting is the devolution of CS education to vocational programming.

If someone is interviewing and they only have Java listed, and their school is known for teaching Java for their introductory classes. They're probably not that strong of a programmer.

Assembler too. For example, Knuth's [M]MIX in The Art of Computer Programming.

That said, this is an introductory programming course, and there are separate courses focused on algorithms (which are not the same as programming). I agree with the article: programming has changed dramatically, while the core of algorithms remains largely unchanged.

Things would be so much better if this were actually true..

I'd argue that SML (or derivative thereof) would make for a better teaching language, for both the lambda calculus aspect and the type theory aspect.

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.

https://news.ycombinator.com/item?id=13098598

A critique along those lines which suggests KRC and Miranda which are in the same vein as SML.

Computer Science has little to do with science, but what it teaches you is certainly closer to science than just building a huge mental index for a bunch of work done by other people.

There's certainly value in that skill, but it has no place in a Computer Science curriculum.

This would be like taking Astrophysics students and telling them to study the details of all of the different kinds of telescopes they can buy.

that's a good point actually. i had scheme, modula and others i don't remember in my undergrad classes. i remember almost nothing from that time. but at the same time i met some students running an LPmud, where i learned LPC, and then i discovered roxen and pike (which is based on LPC) which i used in all my volunteer and fun programming work. in other words all my motivation for learning stuff came from the outside.

I put the scare quotes around "Computer Science", because outside of a single algorithms and data structure course and a single AI course (which was extremely high level), it was purely engineering stuff. One assignment had me deploying stuff with AWS, I was designing wireframes of potential "apps" I could create, and I had to write one HTTP server.

It was kind of fun and it was nice that I was able to complete it quickly, but it really shouldn't be called "Computer Science", it should be called Software Engineering. There's nothing wrong with software engineering, I just view it as distinct-but-related from CS.

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.

There is something really joyful in learning a new language and then implementing a well-known protocol, like HTTP, in that language. You can pick either the agent or server side, and check your work with other well-known agents and servers. In my experience this tends to happen when students like the language they've just learned, regardless of the direction their given by staff. In fact, I'd almost consider it definitional of what it means to like a language - that you'd consider implementing a well-known protocol in it in your free time.

Specifically, it seems to me that colleges becoming more vocational and colleges becoming more expensive are both natural outcomes of the neoliberalisation of all things. I am aware that some students now rationalise their educational investments with the logic you describe above, but I think it's a post-hoc rationalisation.

You can get a good job without going to college, and you can get a good education without paying a gazillion bucks.

A side point, but calling it "vocational" seems a bit euphemistic too. Learning carpentry is a vocation. Getting a business degree is not equivalent to learning carpentry. I might say colleges have become commercialised, rather.

I'm not arguing that compsci should be job training, not at all. My disagreement is solely with this specific claim.

But FWIW, while I understand your analogy, an astrophysics department that didn't tell the students that there are these things called telescopes, and here's why you might use one over the other for various situations, and that they're how you're going to get the observation data you'll test your theories against, would be doing a disservice.

Computer engineering is similar as hard as computer science (don't start the discussion which one is harder ;-) ). What CS departments instead switch to is teaching some shallow, applied programming knowledge.

The vast majority of people on the planet know more than one human language and know zero computer languages. It's literally the opposite of what you're claiming.

My program did Java for the second course, which was very popular in industry and I loathed it.

I do think Python is not so bad to standardize on because it’s stood the test of time and is one of the most popular ways to write code for many disciplines and has applications outside of computer science so it helps everyone that takes the cs requirement even if they aren’t a cs major.

What im saying is Python can even serve as a better version of spreadsheets for folks that aren’t cs.

Problems creep in when the person doesn't learn CS well, chooses an approach that is deeply reliant on overly complex/opaque libraries without good documentation, or the like.

So I graduated with that really helpful knowledge about why modern languages work how they do, but also a lot of practical experience of actually using those modern languages too.

Sticking to only some Algol family language makes people have a severely limited perspective on things.

(Yes, of course, they could teach themselves Python at that point---but if we're talking about things that people can teach themselves, they can teach themselves the whole curriculum and both languages; the debate here is over what the university should hold them accountable to learn).

Depends on your definition of a computer engineer. Dealing with strings in Python vs. dealing with character arrays in C is a world of a difference.

The decision to use Python feels like a solid compromise between giving the students a stair step to applied computer science work, while stripping away the cruft and language-specifics that would distract from implementing the more theoretical learning material

why are you paying a school to teach you something adjacent to what you want to learn so you can learn the thing you need yourself?

It makes a huge difference, whether you have to learn thousands of new words, irregular grammar and (after learning thousands of concepts in the first language) learning a few hundred new concepts, or you learn a computer-understandable language, that has maybe, if very inelegant, 100 keywords, and 100 concepts, most of which you will probably not use often.

Compared to these numbers, the fact, that something is a natural language, has very little influence on the outcome. It is the sheer effort needed to learn a natural language, that makes the difference.

What language you start with and what languages you know on graduating are going to be different. It takes 4 years to get through most bachelors programs (without taking summer terms, very high course loads, or coming in with a bunch of transfer credits). It's no more absurd to start with Scheme than to start with Python when there are at least 7 semesters remaining to learn more.

If a graduate only knows what they learned in CS 1, they aren't a CS graduate even if they got that slip of paper. They conned the school, or the school conned them.

I'll disagree with this, at least in terms of Scheme versus Python.

Python is visually close enough to other languages that the skills you develop to quickly see O(n²) algorithms easily transfer to many other languages. Scheme is very different visually, and so the intuition doesn't transfer as well. Sure, it's possible your intuition is wrong, but when scanning a program intuition can help in the first pass.

That's probably the minority of students though

But I dabbled in PLT in my grad days and have no doubt that there are folks who have your mindset as well.

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.

And no, I wouldn’t recommend starting with BASIC. But starting with Scheme seems like a great choice.

Is that what we need from universities? Is that helping employers? Helping strong or intermediate students?

Edit: I take that back.

> Once you learn Scheme, well now you've learned Scheme.

(Not from SICP but How to Design Programs): The claim is that you’ve learned how to THINK about programming. You understand how to organize and test your code so you can make a larger project.

I think the dismissal of a Scheme-like language as a dead end is shallow, and includes a large assumption about the (lack of an) ecosystem of the language. I think saying more will turn this into a rant.

Because some topics are easy to learn by yourself, and some are not, so the latter ones are better learned in a college setting.

As long as students are exposed to multiple languages, I think starting w/Python is fine. Every language has its issues.

But since I never took compiler theories and other courses on programming language, I never bumped into many of those concepts again except for those where modern languages adopted the same feature, and I ended up having to relearn them anyway. Hence, I would also argue that these days, most students would have been better served starting with a practical language.

Not a unique problem to software either. My sister in-law is a mechanical engineer. Her first employer was upset she didn't know anything practical, and only knew theory. She had to spend years catching up.

I regularly use several programming languages, and tend to pick up a new one every year. I've been spending the last six months studying my second spoken language; I promise you human languages are much harder to learn.

It's not that simple, Python is a fiddly, complex, high-level language that has accreted features in a very ad-hoc way. This makes it very hard to teach and learn in a way that's expected to pay even the most cursory attention to actual rigor. You could probably define a Baby Python subset of the language that's just as simple and rigorously defined as Scheme and teach that, but this isn't how the new MIT intro courses have been designed.

programming languages have a small, manageable and finite set of vocabulary, idioms, and constructs that most languages share but express differently depending on their intended use. a programmer fluent in programming will be able to pick up most languages. how those pieces are cobbled together to form more complicated abstractions becomes the skill obv.

that does not mean they'll be an expert right away, but it does mean they are usually competent enough at minimum to dive in and work with it just like any other tool -- they know they'll need a screwdriver, maybe a hammer, so they look up what it looks like and how it is used.

my daily drivers are python, cmake/Makefiles, c++, and c, with a sprinkling of bash, powershell.

i've worked with microsoft stacks C#/SQL, JavaScript, and i've written a ton of Lua. i've studied concepts and swe fundamentals in languages i don't really write code in and transcribe into code i do intend to write code in. i learned mostly using Lua first, then i picked up c++.

these are just the tools of my job overall. my main skill is communication and learning imo, and knowing which tools are better suited for a task at hand depending on requirements and limitations (mine or technical or both).

When I was in college in the late 1980s, CS was not perceived as the moneymaking career it is today. Accordingly the kids who went into CS were typically the nerds and hackers who truly loved the field.

Many kids now perceive CS as a safe, lucrative career option akin to becoming a doctor or lawyer. It attracts many students who are smart but perhaps not as intrinsically excited about the field. The universities adjusted their curricula to what these students care about: Less beautiful theory, and more practical training.

A similar thing happened in statistics. At one time it was hardcore stats nerds. Now "data science" has brought a ton more people into the field and the teaching methods have changed dramatically.

https://book.realworldhaskell.org/

Oh, and of course it has functions like sdraw or draw-cons-tree when you can print the contents of a list in seconds as an ASCII-ART chart:

https://www.t3x.org/s9fes/draw-tree.scm.html

The file it's in the public domain.

Try that with Python.

Python offers quite good multi-paradigm support and could absolutely be used to explore many key concepts from SICP (granted, nothing is as meta-programmable as the Lisp family, since AST manipulation in other languages requires additional steps to actually obtain an AST). In particular, since Python's object model includes functions, higher-order functions are possible (and indeed, `map` is a builtin, and `reduce` is in the standard library after previous demotion from builtin status). Nowadays of course it's fashionable to litter the code with manifest type hints, which are a distraction to that sort of pedagogy. However, they are still entirely optional, have zero-to-generally-irrelevant effect at runtime, and can simply be disregarded.

But I'm not sure how this addresses what I was saying, which is that the intuitions about algorithms you get working on Python are easier to transfer to popular languages like C++, Java, Javascript, Rust, etc..

Does your comment mean anything other than "I don't like Python very much", and if so what?

You also have an inbuilt ability to learn a computer language. What even is an inbuilt ability?

Programming languages are something you read and write and execute. You can learn many and their definition is precise and limited. It's very easy to be able to pick a programming language and use it in relative low amount of time.

Human languages are absolutely different. You can't easily pick them up and they carry cultural context, regional variations, and a lot of ambiguity and history. Definitions of those languages tend to be complete or prescriptive but descriptive and evolving. The languages are written, spoken, read and listened to. The variation in all of those is immense.

Do you acknowledge any of this or will you double down in the most absurd of points?

These days, employers more or less get what they wanted. We're doomed.

https://en.wikipedia.org/wiki/History_of_Python#Version_1

> During Van Rossum's stay at CNRI, he launched the Computer Programming for Everybody (CP4E) initiative, intending to make programming more accessible to more people, with a basic "literacy" in programming languages, similar to the basic English literacy and mathematics skills required by most employers. Python served a central role in this: because of its focus on clean syntax, it was already suitable, and CP4E's goals bore similarities to its predecessor, ABC.

https://en.wikipedia.org/wiki/ABC_(programming_language)

> It is intended for teaching or prototyping

Community colleges are the cheapest colleges, yet the most vocational.

The most expensive colleges are the Liberal Arts Colleges and the Ivy League, which are the least vocational.

Pyret https://pyret.org/ started out with more or less that ambition I think. IIRC its author had previously tried to work with Python (and its dev team) but gave up.

This is important but doesn't replace having a dual-track intro sequence. The reason one has "physics for physics majors" isn't because physics majors need to learn some of this complicated stuff ASAP. They definitely don't, and I don't doubt students in the program will eventually get a well-rounded education. But it's a good idea to give incoming students a taste of what the field is like as soon as possible, so they can see if they like it or not. (Essentially it's a "weeder", but for the students' sake so they can self-select on interest and not just instructional staff's sake of being elitist.) Probably some (but not all) professors/postdocs/grad students would scramble to teach the more advanced sequence as it is likely more engaging for them than the current intro curriculum.

To be clear I don't think an advanced intro CS can't be in Python on principle, but such a class probably introduces multiple languages to some degree: they could be toy assembly languages or real ones in addition to the majority of the course content in Python.

Not always. Languages can differ radically. If the new language uses concepts you've never encountered before, you're going to need to do the work of learning those new concepts.

An example I've used before: 20 years writing C code for embedded systems won't give you any insight into Haskell's applicatives or monads.

You need to get the ideas first. The language used is the least of your concerns.

This is even more poignant on this era of vibe coding.

Definitely!

This inspired me to list out languages I've learned to at least some minimal level and written programs in. Here they are, with the contexts in which I used them:

BASIC - middle school ;

Fortran - high school ;

C++ - self-taught & later some work;

Pascal - university;

Motorola 68k assembly - university;

Miranda - university (Programming Languages class only);

Ada - university (Programming Languages class only);

Lisp - university & work (CLOS);

sh - work;

ColdFusion - work;

bash - work and personal;

Java - work;

Atmel microcontroller assembly - hobby;

C - hobby (to replace Atmel assembly);

Ruby - work and hobby;

Scala - work;

Elixir - work;

Solidity - work;

Typescript - work and hobby;

Elm - work;

Clojure - work;

Javascript - work;

Python - hobby (with a tiny smattering of work usage over the years)

I acknowledge high schools are notorious in omitting the introduction to proof techniques but it’s a one time hurdle and you end up with a good stuff in your toolbox.

Yeah, but so was BASIC. If Edsger Dijkstra were alive today to write an updated edition of his infamous "How Do We Tell Truths That Might Hurt?" essay, he'd probably just just reuse his quip for BASIC for Python.

My approach is to do what pyret was trying to do while maintaining the python syntax (with minimal deviation where necessary).

Making Python look more like Rust has a lot of support and could correct some of the his historical "injustice" :)

Because of the strong support for keeping python as an approachable imperative language, this will unfortunately require forking.