←back to thread

284 points borski | 2 comments | | HN request time: 0s | source
Show context
keithwinstein ◴[] No.44687148[source]
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 what was basically the first offering of the class that quasi-replaced it (6.01) taught by Leslie Kaelbling, Hal Abelson, and Jacob White.

I would defer to lots of people who know the story better than me, but here's my understanding of the history. When the MIT EECS intro curriculum was redesigned in the 1980s, there was a theory that an EECS education should start with 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)

These were intellectually deep classes, although there was pain in them, and they weren't universally beloved. 6.001 wasn't really about Scheme; I think a lot of the point of using Scheme (as I understood it) is that the language is so minimalist and so beautiful that even this first intro course can be about fundamental concepts of computer science without getting distracted by the language. This intro sequence lasted until the mid-2000s, when enrollment in EECS ("Course 6") declined after the dot-com crash, and (as would be expected, and I think particularly worrisome) the enrollment drop was greater among demographic groups that EECS was eager to retain. My understanding circa 2005 is that there was a view that EECS had broadened in its applications, and that beginning the curriculum with four "deep dives" was offputting to students who might not be as sure that they wanted to pursue EECS and might not be aware of all the cool places they could go with that education (e.g. to robotics, graphics, biomedical applications, genomics, computer vision, NLP, systems, databases, visualization, networking, HCI, ...).

I wasn't in the room where these decisions were made, and I bet there were multiple motivations for these changes, but I understood that was part of the thinking. As a result, the EECS curriculum was redesigned circa 2005-7 to de-emphasize the four 15-unit "deep dives" and replace them with two 12-unit survey courses, each one a survey of a bunch of cool places that EECS could go. The "6.01" course (led by Kaelbling, Abelson, and White) was about robots, control, sensing, statistics, probabilistic inference, etc., and students did projects where the robot drove around a maze (starting from an unknown position) and sensed the walls with little sonar sensors and did Bayesian inference to figure out its structure and where it was. The "6.02" course was about communication, information, compression, networking, etc., and eventually the students were supposed to each get a software radio and build a Wi-Fi-like system (the software radios proved difficult and, much later, I helped make this an acoustic modem project).

The goal of these classes (as I understood) was to expose students to a broad range of all the cool stuff that EECS could do and to let them get there sooner (e.g. two classes instead of four) -- keep in mind this was in the wake of the dot-com crash when a lot of people were telling students that if they majored in computer science, they were going to end up programming for an insurance company at a cubicle farm before their job was inevitably outsourced to a low-cost-of-living country.

6.01 used Python, but in a very different way than 6.001 "used" Scheme -- my recollection is that the programming work in 6.01 (at least circa 2006) was minimal and was only to, e.g., implement short programs that drove the robot and averaged readings from its sonar sensors and made steering decisions or inferred the robot location. It was nothing like the big programming projects in 6.001 (the OOP virtual world, the metacircular evaluator, etc.).

So I don't think it really captures it to say that MIT "switched from Scheme to Python" -- I think the MIT EECS intro sequence switched from four deep-dive classes to two survey ones, and while the first "deep dive" course (6.001) had included a lot of programming, the first of the new survey courses only had students write pretty small programs (e.g. "drive the robot and maintain equal distance between the two walls") where the simplest thing was to use a scripting language where the small amount of necessary information can be taught by example. But it's not like the students learned Python in that class.

My (less present) understanding is that >a decade after this 2006-era curricular change, the department has largely deprecated the idea of an EECS core curriculum, and MIT CS undergrads now go through something closer to a conventional CS0/CS1 sequence, similar to other CS departments around the country (https://www.eecs.mit.edu/changes-to-6-100a-b-l/). But all of that is long after the change that Sussman and Wingo are talking about here.

replies(11): >>44687746 #>>44687781 #>>44688053 #>>44688535 #>>44688621 #>>44688830 #>>44689266 #>>44689635 #>>44692050 #>>44692361 #>>44697928 #
zahlman ◴[] No.44688621[source]
> 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 far more to do with "structure", "architecture" and "functionality" than with "procedure".

replies(3): >>44689202 #>>44689956 #>>44690252 #
kragen ◴[] No.44689202[source]
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 "structures" being discussed are circuit schematics, things like this keyboard I designed last month https://tinyurl.com/23tdsm4c. While SICP does talk about circuit schematics, I don't think anyone would claim that S-expressions are a reasonable alternative way for people to read and write such things.

You're completely confused about Signals and Systems, because you said "functionality", a word which refers to the kind of "functional" a machine might be. In that context, saying that something is "functional" means that it works. But the "functional" that describes Signals and Systems is the mathematical idea of a "function", which is a not-necessarily-computable relation of each possible input to one (possibly not distinct) output. The kinds of "functions" we're talking in S&S are the kinds of functions where you can take the Laplace transform or plot the frequency and phase response. It isn't about functionality at all!

While S-expressions are perfectly capable of expressing ideas like these, and indeed SICM investigates those possibilities in much more detail, SICM hadn't been written yet, and SICP and 6.001 touch on them only briefly. Following SICM I think even its authors were doubtful about whether Scheme was a good medium for working with those ideas.

I don't know anything about Computation Structures, so I can't really say anything about it. Maybe you're right that it would fit perfectly well into 6.001. Apparently it survived the purge; https://ocw.mit.edu/courses/6-004-computation-structures-spr... says:

> This course introduces architecture of digital systems, emphasizing structural principles common to a wide range of technologies. It covers the topics including multilevel implementation strategies, definition of new primitives (e.g., gates, instructions, procedures, processes) and their mechanization using lower-level elements. It also includes analysis of potential concurrency, precedence constraints and performance measures, pipelined and multidimensional systems, instruction set design issues and architectural support for contemporary software structures.

replies(3): >>44689342 #>>44689692 #>>44783789 #
zahlman ◴[] No.44689692[source]
> 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 (and of course typical Algol-family languages).

I understand perfectly well what "functional" means in the context of signals and systems. I took such a course in undergrad, 20+ years ago. But I was using abstract nouns there, rather than adjectives (and writing "function" rather than "functionality" would not really have resolved the issue).

The material in SICP deeply explores the functional programming idiom. A big part of the point of using a Lisp dialect is that functions are first-class (I've watched the OCW lectures; there's a whole section discussing what that means and entails) objects, which enables higher-order functions.

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

replies(2): >>44689911 #>>44690208 #
1. Jtsummers ◴[] No.44689911[source]
You may want to take your issue with the use of the word "procedural" up with the authors of SICP:

> Underlying our approach to this subject is our conviction that “computer science” is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology—the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of “what is.” Computation provides a framework for dealing precisely with notions of “how to.” [Emphasis in original]

-- Preface to the First Edition

replies(1): >>44697037 #
2. zahlman ◴[] No.44697037[source]
That does explain the use of the term. They are reasoning about the systems in terms of what will happen (its procedure), but still describing systems as compositions of parts (as nodes in an AST, effectively) rather than as lists of instructions. And they teach how to analyze problems in order to design systems that way. And, of course, writing the program is inherently a self-directed imperative; you can't simply learn how to write programs and have programs exist as a result — you have to take that initiative.