Parens, parens, every where,
And all the conses link;
Parens, parens, every where,
Nor infix op to think.Why MIT switched from Scheme to Python (2009)
231–240 of 249 posts
Re: Why MIT switched from Scheme to Python (2009)
#232Earlier quoted context omitted.
Thank goodness! Can you imagine a world where just anybody could leap tall buildings? https://www.paulgraham.com/rootsoflisp.html https://www.paulgraham.com/diff.html https://www.paulgraham.com/icad.html
I don't remember who said it, but the Metacircular Evaluator is the real superpower in Lisp/Scheme — even beyond writing macros. It allows you to modify the language itself in ways that are unthinkable in other languages. Whether that is a good thing depends on you.
[deleted]
Re: Why MIT switched from Scheme to Python (2009)
#233Parens, parens, every where, And all the conses link; Parens, parens, every where, Nor infix op to think.
[deleted]
Re: Why MIT switched from Scheme to Python (2009)
#234Earlier quoted context omitted.
There isn't a philosophical difference. Both are problem solving strategies. You would choose one or the other depending on goals and constraints. There isn't a 'philosophical' reason to choose one or the other. In the end the choice wasn't made for philosophical reasons. It was made because the robot library was in Python, or so he thinks. I think this actually shows there was a strong reason to never use Scheme: it…
Thank goodness! Can you imagine a world where just anybody could leap tall buildings? https://www.paulgraham.com/rootsoflisp.html https://www.paulgraham.com/diff.html https://www.paulgraham.com/icad.html
You have to trust revealed preferences, not stated preferences.
Re: Why MIT switched from Scheme to Python (2009)
#235Earlier quoted context omitted.
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…
Btw, I've just read the first section of Chapter 5 [Computing with Register Machines] for the first time, and think it's the best introduction to assembly that I've seen (and I've seen a few). Calling it 'fake' is dismissive. Also, it isn't written in Scheme, but merely described in the native data format: lists of symbols. The next section builds a virtual machine that is written in Scheme to run the code. One of th…
Strange Loop Language Panel - Hickey, Sussman, Wirfs-Brock, Pamer, Alexandrescu, Ashkenas (2011)
https://youtu.be/zhZMaF8vq5Y?t=297
Sussman:
well it's really very hard to find the worst idea because there are so many bad ideas in programming languages. of course the ones that bother me the most are the ones that are designed to keep me from doing what i want. i was after all a libertarian programmer. okay. and so i don't want anybody to tread on me, but the worst features of languages that i can think of -- the really worst thing -- is complex syntax. okay. and as alan perlis quipped, syntactic sugar yields cancer of the semicolon. okay. the problem with complex syntax is that it hides possibly important to understand mechanisms, but more importantly it makes it very difficult to write programs that manipulate programs -- that read them, that write them and analyze them. and that, in fact, i often have programs that write programs that i want to run in-line. for example, numerical programs that are constructed from symbolic algebra expressions. okay. so that's a nice feature of lisp, for example, which has lots of parentheses, is a uniform representation of programs as data and the ability to execute code that you've just constructed. and as a consequence i would say my mantra here is syntax without representation is tyranny.
Re: Why MIT switched from Scheme to Python (2009)
#236Earlier quoted context omitted.
Thank goodness! Can you imagine a world where just anybody could leap tall buildings? https://www.paulgraham.com/rootsoflisp.html https://www.paulgraham.com/diff.html https://www.paulgraham.com/icad.html
I don't remember who said it, but the Metacircular Evaluator is the real superpower in Lisp/Scheme — even beyond writing macros. It allows you to modify the language itself in ways that are unthinkable in other languages. Whether that is a good thing depends on you.
Hal Abelson
InfiniteHistoryProject MIT (2011)
https://youtu.be/r8k8o7zkA1o?t=2532
Abelson:
But Fano did say the key thing. So I talked about what you're doing is making a language and how you make languages to make languages. The technical term for that is an interpreter. So an interpreter is something that effectively takes the description of a language and lets the computer effectively speak that language. And Fano was very-- I mean he would say this in his lectures. I don't think any of the students got it. I didn't get it until like the third time through, where he sort of said the really, really key thing is that you build up complexity by constructing an interpreter. And again, that's the core idea of 6.001, said in a slightly different way.
Re: Why MIT switched from Scheme to Python (2009)
#237Hal Abelson
InfiniteHistoryProject MIT (2011)
https://youtu.be/r8k8o7zkA1o?t=2689
INTERVIEWER: How has introductory curriculum in EECS changed since that time? I mean clearly it's--
ABELSON: Oh, it's changed a lot.
INTERVIEWER: Yeah.
ABELSON: I don't know. People keep using the phrase bittersweet. It's changed in style. So what happened in the department is the department kind of decided that the way students get introduced into the department should become more horizontal and less vertical, by which I mean when you go into the department before the new curriculum, there were a bunch of very intellectually deep courses. So 6.001 really is a deep course in software engineering. And then the idea was well, you shouldn't actually do that because if students want to think about what they want to major in, they ought to get an experience that's a lot more broad. So they should learn not only about software, but something about circuits and something about signal processing and all that. So 6.001 sort of didn't fit into that world. I sort was on the committee. I had this funny feeling. I sort of loved the course. But I also had this feeling that the course needed to change. And both Gerry and I felt that as long as we were part of it, it wasn't going to change. And in fact we consciously got out of it. We had an official, what you call passing of the baton ceremony in one of the lectures where Bob Fano was there as the originator of this, who let us do 6.001. And then Eric Grimson and Duane Boning were there. They were going to take it over. And we kind of officially passed the baton. And we said we now did this in front of 350 student witnesses. We are never going to teach this course again. The department can't ask us. But then what happened is even after we got out of it, the course didn't change as much. And we can flatter ourselves and say well, the ideas were just really great. But sometimes you just need a kick in the pants to go someplace else. So this new department curriculum structure turned out to be the kick in the pants. And so I was part of the group, along with Leslie Kaelbling and Jacob White and Tomas Lozano-Perez, who sort of designed sort of the new course, which consciously was not about 6.001. But a lot of the biggest themes of 6.001 about extraction and modularity and the way you express things, they carry over into the new course. But the new course is also doing robotics. And it's thinking that signal processing. And there's even some stuff about circuits. So it's not a deep course in that sense. And there's a lot of people who have come through MIT--I don't want to take credit for 6.001 and that, but I want to say it was a very deep experience in how you think of software--who criticized what we did. And they say they really miss it. They talk about their own intellectual development as programmers. It was just profoundly influenced by that kind of very--we would sit in that class and talk about the philosophy sometimes. The new course does not do that in the same way. On the other hand, you have to sort of ask what's the population you're serving? And the fact that you talk to the minority of students who really, really glommed on to our way of thinking and they say, gee, we really wish MIT were still doing that. I don't know what the right way of serving the most students are. But in any case we're just doing something rather different in motivation now.
INTERVIEWER: So it's broader, but less deep.
ABELSON: And very consciously less deep.
Re: Why MIT switched from Scheme to Python (2009)
#238Earlier quoted context omitted.
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…
Btw, I've just read the first section of Chapter 5 [Computing with Register Machines] for the first time, and think it's the best introduction to assembly that I've seen (and I've seen a few). Calling it 'fake' is dismissive. Also, it isn't written in Scheme, but merely described in the native data format: lists of symbols. The next section builds a virtual machine that is written in Scheme to run the code. One of th…
I can see how 6.001 was a bit like jumping into the deep end to learn to swim.
Starting from, "To design a register machine, we must design its data paths (registers and operations) and the controller that sequences these operations." In less than 5,000 words it proceeds to implementing recursive procedure calls in what amounts to assembly:
(controller
(assign continue (label fact-done)) ; set up final return address
fact-loop
(test (op =) (reg n) (const 1))
(branch (label base-case))
(save continue) ; Set up for the recursive call
(save n) ; by saving n and continue.
(assign n (op -) (reg n) (const 1)) ; Set up continue so that the
(assign continue (label after-fact)) ; computation will continue
(goto (label fact-loop)) ; at after-fact when the
after-fact ; subroutine returns.
(restore n)
(restore continue)
(assign val (op *) (reg n) (reg val)) ; val now contains n(n - 1)!
(goto (reg continue)) ; return to caller
base-case
(assign val (const 1)) ; base case: 1! = 1
(goto (reg continue)) ; return to caller
fact-done)
(define (factorial n)
(if (= n 1)
1
(* (factorial (- n 1)) n)))
Re: Why MIT switched from Scheme to Python (2009)
#239Earlier quoted context omitted.
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…
The fuller excerpt concretely put in §3.1.3 "The Costs of Introducing Assignment":
"So long as we do not use assignments, two evaluations of the same procedure with the same arguments will produce the same result, so that procedures can be viewed as computing mathematical functions. Programming without any use of assignments, as we did throughout the first two chapters of this book, is accordingly known as functional programming."
Re: Why MIT switched from Scheme to Python (2009)
#240Earlier quoted context omitted.
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 difference between mathematical functions and computer procedures. Proc…
I appreciate it. The observation was really intended to be about the semantic drift, and the odd coincidence of language.
[deleted]