Why MIT switched from Scheme to Python (2009) • Hacker News Board

Re: Why MIT switched from Scheme to Python (2009)

#161

Post by temporallobe » Fri, Jul 25, 2025, 11:58 PM UTC

lokar wrote: post #60

temporallobe wrote: post #50

This is just an introductory language and if you’re in a CS program, you’ll definitely move on to more advanced ones. It actually makes sense to switch to Python since it’s far more ubiquitous and accessible than Scheme. Scheme is not widely used in commercial software development, but still enjoys a presence in academia. Python has strong presence in both. On the other hand, Pascal was my “introductory” programming…

This is one of many divides in the field that makes many general discussions hard. There are many people who think of themselves as a “X programmer” (and perhaps Y and Z), and managers/companies looking for them. Then there are people who think of themselves as software engineers, and the language does not really matter (and companies that hire for that). If often see the two camps talking past each other.

I certainly consider myself a software engineer first and programmer second, and you’re right, the language doesn’t matter. I recently got a position developing in Python having never really used it professionally, but it’s so similar to other interpreted languages I knew so I was able to jump right in and start making meaningful contributions. Often we are expected to learn new languages, which is exactly how I picked up the 10ish languages I can confidently say I’m good in, despite never having been formally trained in those. Most common languages don’t stray from certain basic principles anyway.

Re: Why MIT switched from Scheme to Python (2009)

#162

Post by StellarScience » Sat, Jul 26, 2025, 12:01 AM UTC

zahlman wrote: post #125

keithwinstein wrote: post #75

This story has been reposted many times, and I think GJS's remarks (as recorded by Andy Wingo) are super-interesting as always, but this is really not a great account of "why MIT switched from Scheme to Python." Source: I worked with GJS (I also know Alexey and have met Andy Wingo), and I took 6.001, my current research still has us referring to SICP on a regular basis, and in 2006 Kaijen Hsiao and I were the TAs for…

> There were four 15-unit courses, each about one of these "languages": The description you offer is strange to me. The Lisp family of languages are multi-paradigm (arguably paradigm-independent) and can hardly be called "procedural". The core material of SICP revolves around considering the "means of combination" and "means of abstraction" offered by a programming language — concepts that sound to me like they have…

You're absolutely right that "procedural", at least as I understand the word in 2025, is a poor label for 6.001.

6.001 taught 'define' and 'let' but didn't teach 'set!' until week 6 or so. So we learned functions, variables, scopes, recursion, lambdas, strings, numbers, symbols, lists, map, filter, flatten, and more - all without ever modifying a variable. That's very "functional".

Once we learned that it was possible modify existing variables, we learned object-oriented programming; objects were just lambdas with closures that took messages indicating which function to call. We then learned a fake assembly language written in scheme that had both an interpreter and a compiler, also written in scheme. While "procedural" feels wrong, I'm not sure what label one could apply to all this...

Re: Why MIT switched from Scheme to Python (2009)

#163

Post by leoc » Sat, Jul 26, 2025, 12:24 AM UTC

lupusreal wrote: post #44

kec wrote: post #37

Earlier quoted context omitted.

Computer Engineering is its own discipline, typically lumped with Electrical Engineering, which is more about system architecture and design and only touches on programming at a low level such as device firmware. What I think you're really lamenting is the devolution of CS education to vocational programming.

I think he meant software engineering.

“Software Engineering” tends to be about project management: schedules and organisation, estimation, defect rates and so on. For vocational training on existing IT systems (including some coding), which I assume is more what the course focused on, then “Management Information Systems” or “Information Technology” would be the more traditional names IIUC.

Re: Why MIT switched from Scheme to Python (2009)

#164

Post by twoodfin » Sat, Jul 26, 2025, 12:26 AM UTC

StellarScience wrote: post #162

zahlman wrote: post #125

Earlier quoted context omitted.

> There were four 15-unit courses, each about one of these "languages": The description you offer is strange to me. The Lisp family of languages are multi-paradigm (arguably paradigm-independent) and can hardly be called "procedural". The core material of SICP revolves around considering the "means of combination" and "means of abstraction" offered by a programming language — concepts that sound to me like they have…

You're absolutely right that "procedural", at least as I understand the word in 2025, is a poor label for 6.001. 6.001 taught 'define' and 'let' but didn't teach 'set!' until week 6 or so. So we learned functions, variables, scopes, recursion, lambdas, strings, numbers, symbols, lists, map, filter, flatten, and more - all without ever modifying a variable. That's very "functional". Once we learned that it was possibl…

Wizardry!

Re: Why MIT switched from Scheme to Python (2009)

#165

Post by senderista » Sat, Jul 26, 2025, 12:28 AM UTC

dawnofdusk wrote: post #55

Karrot_Kream wrote: post #47

Earlier quoted context omitted.

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…

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…

Similarly for math. I had to take a linear algebra class as a math major that was mostly populated by engineering majors and it was painful (given that they were allergic to proofs).

Re: Why MIT switched from Scheme to Python (2009)

#166

Post by leoc » Sat, Jul 26, 2025, 12:34 AM UTC

zozbot234 wrote: post #119

MontyCarloHall wrote: post #14

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 a…

> Whereas Python is excellent for teaching applied computer engineering, because it's essentially executable pseudocode for imperative languages 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 Bab…

> You could probably define a Baby Python subset of the language that's just as simple and rigorously defined as Scheme and teach that

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.

Re: Why MIT switched from Scheme to Python (2009)

#167

Post by kragen » Sat, Jul 26, 2025, 12:34 AM UTC

zahlman wrote: post #155

kragen wrote: post #149

Earlier quoted context omitted.

SICP is fundamentally about the notion that programs are primarily a means of communication between people, being written by people for other people to read, and only secondarily a thing for computers to execute. And it really opened my eyes to the landscape of programming paradigms that exist—indeed, it continues to do so! But your comment is completely off-base. In Circuits and Electronics, as I understand it, the…

> But your comment is completely off-base. I think it is rather your reply that is off-base; or else I have not made myself sufficiently clear. My point was simply that the words used to describe the other courses are better fits for what SICP teaches than "procedural", which is a poor fit for describing Lisp-family languages and would make more sense applied to other contemporary languages like COBOL and FORTRAN (an…

Your comments are clear enough; they're just mistaken.

Lisp dialects generally do not support mathematical functions, despite supporting the functional-programming idiom, which is inspired by mathematical functions. Rather, they support procedures, which in most Lisps are called "functions". In Scheme, however, the Lisp they chose for the course, they are called "procedures", an intentional choice to avoid creating precisely the kind of confusion you are experiencing. Lisp "functions", like procedures in most other languages, can fail to terminate, can raise an error, can have side effects, and can depend on mutable state.

Mathematical functions cannot do any of these things. If they could, it wouldn't make much sense to take their Laplace transforms!

The five chapters of SICP (I recommend http://sarabander.github.io/sicp/html/index.xhtml) are:

- 1 Building Abstractions with Procedures

- 2 Building Abstractions with Data

- 3 Modularity, Objects, and State

- 4 Metalinguistic Abstraction

- 5 Computing with Register Machines

— ⁂ —

You said:

> Nothing in my comment is about modelling anything to do with electronics in software.

You are mistaken about that. The part of your comment that is about modelling something to do with electronics in software is the part where you replied to a comment saying:

> ... four "deep dives" into the four "languages of engineering." There were four 15-unit courses, each about one of these "languages":

> - 6.001: Structure and Interpretation of Computer Programs (the "procedural" language, led by Abelson and Sussman)

> - 6.002: Circuits and Electronics ("structural" language)

> - 6.003: Signals and Systems ("functional" language)

> - 6.004: Computation Structures ("architectural" language)

Your comment in reply said:

> Lisp (...) can hardly be called "procedural". The core material of SICP revolves around (...) concepts that (...) have far more to do with "structure", "architecture" and "functionality" [sic] than with "procedure".

That is, you were explicitly asserting that the core material of SICP was concerned with "structure", "architecture", and "functions" in the sense of the core material of those courses, rather than only or even primarily procedural abstraction. However, two of those four courses—specifically, 6.002 and 6.004—were concerned almost exclusively with modeling electronics. (An awful lot of the "systems" in 6.003 are also electronic, but that's beside the point.) However, as you know, 6.001, SICP, and Lisp are concerned exclusively with modeling things in software.

Modeling electronics in software is a reasonable thing to do, and Lisp is a reasonable medium to do it in, but you need to understand the structural, architectural, and (at least for analog electronics) functional angles on the electronics in order to do that. None of that is part of SICP or 6.001, and Lisp is not a reasonable medium for describing electronic systems from at least the structural and functional angles. You need schematics, pole-zero diagrams, and Bode plots. If you remembered what you studied in that course 20+ years ago this would be obvious to you.

Re: Why MIT switched from Scheme to Python (2009)

#168

Post by Jtsummers » Sat, Jul 26, 2025, 12:39 AM UTC

StellarScience wrote: post #162

zahlman wrote: post #125

Earlier quoted context omitted.

> There were four 15-unit courses, each about one of these "languages": The description you offer is strange to me. The Lisp family of languages are multi-paradigm (arguably paradigm-independent) and can hardly be called "procedural". The core material of SICP revolves around considering the "means of combination" and "means of abstraction" offered by a programming language — concepts that sound to me like they have…

You're absolutely right that "procedural", at least as I understand the word in 2025, is a poor label for 6.001. 6.001 taught 'define' and 'let' but didn't teach 'set!' until week 6 or so. So we learned functions, variables, scopes, recursion, lambdas, strings, numbers, symbols, lists, map, filter, flatten, and more - all without ever modifying a variable. That's very "functional". Once we learned that it was possibl…

Given their definition of procedural, the term makes sense. The book is about processes and procedures that describe how they're executed or things are computed, versus describing what is computed (mathematical sense, declarative or more declarative, closer to some popular meanings of functional programming today).

They define functional programming as "[p]rogramming without any use of assignments". Which would be a subset of procedural programming in the sense that they mean it.

They also contrast imperative and functional programming (the first being with assignments and mutations, the latter without). Both imperative and functional programming can reasonably fall under procedural programming using their definitions.

Re: Why MIT switched from Scheme to Python (2009)

#169

Post by kragen » Sat, Jul 26, 2025, 12:40 AM UTC

swannodette wrote: post #151

kragen wrote: post #149

Earlier quoted context omitted.

SICP is fundamentally about the notion that programs are primarily a means of communication between people, being written by people for other people to read, and only secondarily a thing for computers to execute. And it really opened my eyes to the landscape of programming paradigms that exist—indeed, it continues to do so! But your comment is completely off-base. In Circuits and Electronics, as I understand it, the…

> Following SICM I think even its authors were doubtful about whether Scheme was a good medium for working with those ideas. Hrm https://mitp-content-server.mit.edu/books/content/sectbyfn/b...

This looks awesome! Maybe they were joking.

Re: Why MIT switched from Scheme to Python (2009)

#170

Post by nathan_douglas » Sat, Jul 26, 2025, 12:41 AM UTC

zahlman wrote: post #125

keithwinstein wrote: post #75

This story has been reposted many times, and I think GJS's remarks (as recorded by Andy Wingo) are super-interesting as always, but this is really not a great account of "why MIT switched from Scheme to Python." Source: I worked with GJS (I also know Alexey and have met Andy Wingo), and I took 6.001, my current research still has us referring to SICP on a regular basis, and in 2006 Kaijen Hsiao and I were the TAs for…

> There were four 15-unit courses, each about one of these "languages": The description you offer is strange to me. The Lisp family of languages are multi-paradigm (arguably paradigm-independent) and can hardly be called "procedural". The core material of SICP revolves around considering the "means of combination" and "means of abstraction" offered by a programming language — concepts that sound to me like they have…

I'm a bit disappointed by some of the responses you received and that you were apparently downvoted.

Here's some text from Chapter 1 of the book that might make this clearer:

> Procedures, as introduced above, are much like ordinary mathematical functions. They specify a value that is determined by one or more parameters. But there is an important diﬀerence between mathematical functions and computer procedures. Procedures must be eﬀective.

> As a case in point, consider the problem of computing square roots. We can define the square-root function as √x = the y such that y≥0 and y^2 = x .

> This describes a perfectly legitimate mathematical function. We could use it to recognize whether one number is the square root of another, or to derive facts about square roots in general. On the other hand, the definition does not describe a procedure. Indeed, it tells us almost nothing about how to actually find the square root of a given number. It will not help matters to rephrase this definition in pseudo-Lisp:

    (define (sqrt x)
      (the y (and (>= y 0)
        (= (square y) x))))

> This only begs the question.

> The contrast between function and procedure is a reflection of the general distinction between describing properties of things and describing how to do things, or, as it is sometimes referred to, the distinction between declarative knowledge and imperative knowledge. In mathematics we are usually concerned with declarative (what is) descriptions, whereas in computer science we are usually concerned with imperative (how to) descriptions.

[There's more after this, but it is off-topic for our purposes.] IMHO you're not wrong and you shouldn't've been downvoted. I think there's just an issue with semantic drift and evolving terminology and map-is-not-the-territory and so forth going on.