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)
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.
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.
I was one of the last batches of students on the old Scheme curriculum. I absolutely loved it! Understanding that all loops could be done via recursion, and what a side effect is, is what fundamentally made me fall in love with CS. I've heard good things about the new, and now newer, curriculum but I know I wouldn't have had the awakening I did if it weren't for scheme.
RIP SICP
---
ps another fun story: we had some test where we were allowed to bring in 1 page of reference notes. And turns out the entire scheme specification is short enough to fit on a double sided page if condensed. So my friend, mostly in jest, brought the whole Scheme specification to the test with him and figured every possible question could be answered that way!
And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all.
That is the essence of Python's strength ... the eco-system. And the comment about engineering becoming the art of trying to reason about half-documented toys from the huge grab bag of packages is exactly on point relative to the risk and challenge of this transition.
The move away from Scheme has always saddened me. The first thing we learned in 6.001 was abstraction and invariance. These are still the core of writing good software. I still use these principles every day. There is a purity to Scheme. It is a beautiful light-weight language anyone can learn over a weekend. It does nothing magical for you which means you get to / have to build everything you want and you must understand how it fits together.
Ga Tech used to teach Scheme as an intro to CS course. I vividly remember sitting in lecture and being struck w/ the implications of functional programming as the professor said you could pass functions into functions and modify them. It was as formative of a moment as my 2nd Grade teacher showing us a really complex looking (at the time) rainbow flower in LOGO (she had one of few color Mac classic), and showing us it was simply the work of drawing the path of one petal, then repeating same “work” after changing two values (starting angle and color).
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 language (I already knew BASIC pretty well at that point), but it certainly wasn’t the only one in my program - we did Perl, Prologue, C, C++, etc.
In a professional software development career, it certainly won’t be the last language you’ll
learn.
A good computer science program should expose students to lots of different languages and teach them that they are all different for valid reasons. There are many different paradigms and there is a rich history of languages at this point.
The issue with Scheme is that it has very little relevance outside of academia. It's fine for making students learn that as an exercise to teach them that there are different ways of doing things and some of those ways can be wonderful. But you need to learn more than just that to become a proper computer scientist or software engineer.
Python is a useful language to know just because of how useful it is. But it's not a great language to teach functional or object oriented programming. I would actually use different languages for teaching those concepts. Back when I studied, those languages where Gofer and Smalltalk. Gofer is a Haskell dialect/predecessor. Haskell already existed but wasn't that common yet. Scheme was already old news in the early nineties.
I actually learned Java during the summer of 1995 as a second year student as a preparation to teach it to first year students. My university was progressive like that. I learned C in my first year. They switched to C++ the next year. By the fourth year I had been exposed to Prolog, Java, Delphi, C, C++, Gofer, Smalltalk, Modula, Pascal, Lisp (in various variants) and probably a few other things that I've since forgotten.
One of the wonderful courses we got taught us all about the UNIX command line (mostly HP UNIX at the time, and a little bit of Solaris). Things like pipes & filters, regexes, AWK, etc. Different courses would expose you to different tools and languages. I followed a few courses on expert systems and bayesian belief networks. That just required you to deal with the lisp dialects used for that. The people giving these courses were proper researchers too. And they just used what they would use themselves.
I did not fully appreciate it at the time, but Utrecht university had a wonderful computer science faculty with some amazing people. I learned functional programming from a young enthusiastic Erik Meijer who later joined Microsoft, Facebook etc. and built things like F#, LINQ and a few other things.
Berkeley seems to want to slice the baby in half. cs61a teaches in Python but then retains the implementation of a Scheme interpreter. They don't use SICP anymore. They use John DeNero's online text, Composing Programs.
BTW, my complaint about Scheme in 61a was that after the class, the department never used it again. They didn't even have the decency to use Guile or some standard Scheme. Instructional Computing had some hacked up something Scheme.
> Nowadays you muck around with incomprehensible or nonexistent man pages for software you don’t know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts.
Probably the best way, and maybe the only way, to learn this is by doing it. That's how I learned it, with no formal training in programming.
What I learned from SICP and Sussman's other books I would never have figured out any other way. I don't think the world is really as different as Sussman says it is here, and I think the programming world lost something special with this change.
The book lives on anyway, and he'll always be one of my heroes.
>In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. ... But programming now isn’t so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don’t know who wrote. 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 that how people read code these days? I've always been weaker at reading code, but great at writing it. Iama Data Scientist, which explains why; I haven't had to read tons of code throughout my career. The topic kind of scares me. His description scares me even more.
One of the less obvious benefits of teaching a mainstream language (or a "hobby" language—the kind you might pick up on the weekend for some hacking) is all the folks who don't go on to graduate with a CS degree. Will Scheme teach interesting ideas? Of course. Will someone who doesn't code for a living download a scheme compiler and write a script five years after graduating? Not a chance. Ten years? There's no universe.
Front-loading the mainstream language means you're not just teaching CS fundamentals, you're giving someone a tool that they can readily pick up and use in their real life for real tasks. It's the same as having home maintenance as a component of your basic high school shop class instead of how to rebuild a carburetor: unless you're working with carburetors for a living, that's an unlikely skill that you'd reach for. But knowing how to correctly hang a picture, replace an electrical outlet, or patch drywall is something almost anyone can put to good use ten, twenty, thirty years on.
There's probably a middle ground somewhere. IMHO, SICP leans a little too heavily on the homoiconicity of Scheme for its choice of exercises. Which is intellectually nifty but it could also include exercises from something like Crafting Interpreters (Nystrom) where you would build up step-by-step to an interpreter of a non-Scheme-like language, using Scheme.
I've come full circle from the first answer given. I wanted to get into neural nets a couple years ago. I chose Clojure because I knew I would be interfacing with components I didn't understand and wanted a system that helped me explore.
build a scheme interpreter in python = best of both worlds??
I love SICP - easily in my top ten most influential CS books. But I've basically never seen a real Scheme job. I do think it's reasonable to at least try to instill both foundational and marketable skills early.
Related: when UT Austin computer science dropped Haskell for Java for it's first course in 2001.
Dijkstra on Haskell and Java
https://chrisdone.com/posts/dijkstra-haskell-java/
"A fundamental reason for the preference is that functional programs are much more readily appreciated as mathematical objects than imperative ones, so that you can teach what rigorous reasoning about programs amounts to."
A lot of this boils down to what you can convince the prof to teach. For most professors, teaching CS1 is a service and does not advance their research. Fewer faculty today are willing to learn Scheme just because it may be marginally better for students, according to some people.
16 years later, I'm still disappointed about this decision. The justification for it is just awful:
"6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.
But programming now isn’t so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don’t know who wrote."
This is just false. Engineering is still about taking small parts you understand entirely and using simple techniques to compose them into larger things you want. Sussman's justification is an abject surrender to shitty complexity. Engineers need to develop a taste for simplicity and elegance, especially at the beginning of their education.
Incidentally, an overlooked advantage of teaching in Scheme is that it levels the playing field, as pre-undergrad programming classes almost never use functional languages.
I think it was also one of the first freely available courses for learning Python. It’s been more than 10 years since I took that course on edX and I still appreciate it. Robot vacuum exercises were a lot of fun.
I know, that I am just a single data point, but Scheme took the fun out of programming in my computer science studies. Of course I do understand, that it makes teaching lambda calculus obviously a lot easier and is a better vehicle for teaching theoretical computer science concepts, than say, Python.
But at the same time Scheme is limited to academia and has near zero practitioners outside academia. So the Scheme ecosystem is tiny compared to Python or Java.
Yes, you could argue, that "Computer Science" is not mere "Software Development" and academia shouldn't bow down to industry and shouldn't be a tool to provide "programmers". But again it's also important for motivation to apply the language, algorithms and concepts in other fields. Learning also has to do a lot with motivation and experimentation.
And this is a "hot take", but I always had the feeling back then, that courses are often bound to the professors curriculum and sometimes their books, so I am not surprised about resistance to changing the language.
That said, I was glad, when the Scheme lectures were over. Now I am a Software developer for more than a decade and have to admit, that learning Scheme didn't make me a better programmer at all. If I'd stayed in academia I might have a different opinion.
Brown CS (back in 2004) gave you a choice: you could either take a 2-class intro sequence that started with Scheme and eventually OCaml before moving into OOP with Java, or you could start with Java from the get-go and make cool/flashy projects like Tetris by the end. Both course sequences were supposed to bring you to roughly the same place by the end.
I took the Scheme path and feel great about having a deep theoretical foundation in CS, but I know plenty of folks who started with the fun/shiny stuff and became amazing software engineers. So all in all I'm really glad they gave us a choice.
I will admit that there were people in my classes who didn't really understand what they were getting themselves into and possibly would have benefited from starting with Python or Java and getting more inspired about building cool projects. It really was a YMMV ¯\_(ツ)_/¯
When I read this I just feel like Sussman is getting out of touch and maybe a little disillusioned. From the wording he seems annoyed about the change, isn't even sure why it was made "probably because there's some library for robots", has gone from someone who would have a complete understanding of complex systems to someone who sounds more like a frustrated beginner. "Doing basic science on libraries to see how they behave" instead of grabbing the source and looking at it - he is expressing the view of someone who wants to complete their ticket in Jira without too much effort and go home for the night rather than someone with an actual curiosity and enjoyment of what they are doing.
Scheme it's far easier to grasp. With SICP you basically rewrite a Scheme within a Scheme. And you teach Calculus to the interpreter to solve further problems.
Why MIT switched from Scheme to Python (2009)
(wisdomandwonder.com)239 points by borski 21 hours ago | 190 comments
Comments
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.
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.
RIP SICP
---
ps another fun story: we had some test where we were allowed to bring in 1 page of reference notes. And turns out the entire scheme specification is short enough to fit on a double sided page if condensed. So my friend, mostly in jest, brought the whole Scheme specification to the test with him and figured every possible question could be answered that way!
On the other hand, Pascal was my “introductory” programming language (I already knew BASIC pretty well at that point), but it certainly wasn’t the only one in my program - we did Perl, Prologue, C, C++, etc.
In a professional software development career, it certainly won’t be the last language you’ll learn.
The issue with Scheme is that it has very little relevance outside of academia. It's fine for making students learn that as an exercise to teach them that there are different ways of doing things and some of those ways can be wonderful. But you need to learn more than just that to become a proper computer scientist or software engineer.
Python is a useful language to know just because of how useful it is. But it's not a great language to teach functional or object oriented programming. I would actually use different languages for teaching those concepts. Back when I studied, those languages where Gofer and Smalltalk. Gofer is a Haskell dialect/predecessor. Haskell already existed but wasn't that common yet. Scheme was already old news in the early nineties.
I actually learned Java during the summer of 1995 as a second year student as a preparation to teach it to first year students. My university was progressive like that. I learned C in my first year. They switched to C++ the next year. By the fourth year I had been exposed to Prolog, Java, Delphi, C, C++, Gofer, Smalltalk, Modula, Pascal, Lisp (in various variants) and probably a few other things that I've since forgotten.
One of the wonderful courses we got taught us all about the UNIX command line (mostly HP UNIX at the time, and a little bit of Solaris). Things like pipes & filters, regexes, AWK, etc. Different courses would expose you to different tools and languages. I followed a few courses on expert systems and bayesian belief networks. That just required you to deal with the lisp dialects used for that. The people giving these courses were proper researchers too. And they just used what they would use themselves.
I did not fully appreciate it at the time, but Utrecht university had a wonderful computer science faculty with some amazing people. I learned functional programming from a young enthusiastic Erik Meijer who later joined Microsoft, Facebook etc. and built things like F#, LINQ and a few other things.
Ask HN: How has MIT's switch from Scheme to Python worked out? - https://news.ycombinator.com/item?id=24960481 - Nov 2020 (1 comment)
Why MIT uses Python instead of Scheme for its undergraduate CS program (2009) - https://news.ycombinator.com/item?id=18782101 - Dec 2018 (136 comments)
Why MIT Switched from Scheme to Python (2009) - https://news.ycombinator.com/item?id=14167453 - April 2017 (97 comments)
Ask HN: Python or Scheme? - https://news.ycombinator.com/item?id=2523432 - May 2011 (11 comments)
Videos for MIT 6.00 - Python Version - https://news.ycombinator.com/item?id=1045114 - Jan 2010 (1 comment)
Why MIT now uses python instead of scheme for its undergraduate CS program - https://news.ycombinator.com/item?id=842333 - Sept 2009 (38 comments)
Python based MIT 6.00 | Intro to Computer Science and Programming - https://news.ycombinator.com/item?id=819734 - Sept 2009 (6 comments)
Chiming in on the MIT Scheme to Python Switch - https://news.ycombinator.com/item?id=622261 - May 2009 (7 comments)
Why Did M.I.T. Switch from Scheme to Python? - https://news.ycombinator.com/item?id=602307 - May 2009 (65 comments)
Why MIT switched from Scheme to Python - https://news.ycombinator.com/item?id=530605 - March 2009 (128 comments)
MIT replacing Scheme with Python for Intro CS class - https://news.ycombinator.com/item?id=75401 - Nov 2007 (16 comments)
---
Berkeley version:
Scheme vs. Python (2011) - https://news.ycombinator.com/item?id=9973156 - July 2015 (118 comments)
SICP (Python Version) - https://news.ycombinator.com/item?id=3718364 - March 2012 (18 comments)
SICP taught in Python 3 - UC Berkeley online - https://news.ycombinator.com/item?id=3491142 - Jan 2012 (25 comments)
SICP in Python - https://news.ycombinator.com/item?id=3141996 - Oct 2011 (49 comments)
https://cs61a.org/
https://www.composingprograms.com
BTW, my complaint about Scheme in 61a was that after the class, the department never used it again. They didn't even have the decency to use Guile or some standard Scheme. Instructional Computing had some hacked up something Scheme.
Probably the best way, and maybe the only way, to learn this is by doing it. That's how I learned it, with no formal training in programming.
What I learned from SICP and Sussman's other books I would never have figured out any other way. I don't think the world is really as different as Sussman says it is here, and I think the programming world lost something special with this change.
The book lives on anyway, and he'll always be one of my heroes.
Is that how people read code these days? I've always been weaker at reading code, but great at writing it. Iama Data Scientist, which explains why; I haven't had to read tons of code throughout my career. The topic kind of scares me. His description scares me even more.
Front-loading the mainstream language means you're not just teaching CS fundamentals, you're giving someone a tool that they can readily pick up and use in their real life for real tasks. It's the same as having home maintenance as a component of your basic high school shop class instead of how to rebuild a carburetor: unless you're working with carburetors for a living, that's an unlikely skill that you'd reach for. But knowing how to correctly hang a picture, replace an electrical outlet, or patch drywall is something almost anyone can put to good use ten, twenty, thirty years on.
I've come full circle from the first answer given. I wanted to get into neural nets a couple years ago. I chose Clojure because I knew I would be interfacing with components I didn't understand and wanted a system that helped me explore.
I love SICP - easily in my top ten most influential CS books. But I've basically never seen a real Scheme job. I do think it's reasonable to at least try to instill both foundational and marketable skills early.
Dijkstra on Haskell and Java https://chrisdone.com/posts/dijkstra-haskell-java/ "A fundamental reason for the preference is that functional programs are much more readily appreciated as mathematical objects than imperative ones, so that you can teach what rigorous reasoning about programs amounts to."
This is just false. Engineering is still about taking small parts you understand entirely and using simple techniques to compose them into larger things you want. Sussman's justification is an abject surrender to shitty complexity. Engineers need to develop a taste for simplicity and elegance, especially at the beginning of their education.
Incidentally, an overlooked advantage of teaching in Scheme is that it levels the playing field, as pre-undergrad programming classes almost never use functional languages.
But at the same time Scheme is limited to academia and has near zero practitioners outside academia. So the Scheme ecosystem is tiny compared to Python or Java.
Yes, you could argue, that "Computer Science" is not mere "Software Development" and academia shouldn't bow down to industry and shouldn't be a tool to provide "programmers". But again it's also important for motivation to apply the language, algorithms and concepts in other fields. Learning also has to do a lot with motivation and experimentation.
And this is a "hot take", but I always had the feeling back then, that courses are often bound to the professors curriculum and sometimes their books, so I am not surprised about resistance to changing the language.
That said, I was glad, when the Scheme lectures were over. Now I am a Software developer for more than a decade and have to admit, that learning Scheme didn't make me a better programmer at all. If I'd stayed in academia I might have a different opinion.
I took the Scheme path and feel great about having a deep theoretical foundation in CS, but I know plenty of folks who started with the fun/shiny stuff and became amazing software engineers. So all in all I'm really glad they gave us a choice.
I will admit that there were people in my classes who didn't really understand what they were getting themselves into and possibly would have benefited from starting with Python or Java and getting more inspired about building cool projects. It really was a YMMV ¯\_(ツ)_/¯
Online SICP: http://sarabander.github.io/sicp/