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.
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.
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).
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!
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
"And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all."
I was from the same "Nouvelle AI"/Robotics cohort as Leslie Kaelbling. Autonomous Robotics in AI back then was a fairly small community, so everyone (at least in the nato and friends) knew each other from conferences and workshops.
Having written kernel and interface libraries for those type of robot systems in those days, it was not that much work that it would need to be an issue determining language choice.
My uninformed guess based on what lived in the community at the time would be that the teachings were so focussed on the ideas of physical grounding, control paradigms and systems, "the world is its own best model" and reaction against the symbolic reasoning systems that came before, that Scheme/Lisp had to go because it was an icon of the symbolic paradigm, and that in the new 'subsymbolic' world we did not pay attention to the programming language at all, because basically it was all data/signal flow and intercoupled and layered differential equations from sensors to actuators anyways.
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.
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 ¯\_(ツ)_/¯
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."
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.
48 comments
[ 3.7 ms ] story [ 71.0 ms ] threadOnline SICP: http://sarabander.github.io/sicp/
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!
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.
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 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.
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)
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.
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 diffe...
I was from the same "Nouvelle AI"/Robotics cohort as Leslie Kaelbling. Autonomous Robotics in AI back then was a fairly small community, so everyone (at least in the nato and friends) knew each other from conferences and workshops.
Having written kernel and interface libraries for those type of robot systems in those days, it was not that much work that it would need to be an issue determining language choice.
My uninformed guess based on what lived in the community at the time would be that the teachings were so focussed on the ideas of physical grounding, control paradigms and systems, "the world is its own best model" and reaction against the symbolic reasoning systems that came before, that Scheme/Lisp had to go because it was an icon of the symbolic paradigm, and that in the new 'subsymbolic' world we did not pay attention to the programming language at all, because basically it was all data/signal flow and intercoupled and layered differential equations from sensors to actuators anyways.
From my perspective, a tragedy.
We've had a SICP discussion/reading group running for a few months. [Sundays at 3pm Pacific]
Currently we are looking at §4.4 — Logic Programming. [0]
Includes the book's stream based implementation of a pattern-matcher and unification (properly in scheme).
Looking at connections to Hindley–Milner.
see also: miniKanren, The Reasoned Schemer, @will_byrd
[0]: https://sarabander.github.io/sicp/html/4_002e4.xhtml#g_t4_00...
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.
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 ¯\_(ツ)_/¯
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.