Why MIT switched from Scheme to Python (2009) | Hacker News Reader

Why MIT switched from Scheme to Python (2009)

wisdomandwonder.com

284 pointsborski232 comments

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.

Thanks for this detailed explanation.

A semi-off-topic side question:

> 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).

What was the reason why the software radios proved difficult?

Not OP but in general sourcing software and hardware radios in that time was very difficult. There weren’t good open-source implementations and everything had to be sorta reverse engineered which meant that anyone with the skill to do that was selling it for a lot of dollars.

Source: did 10 years in telecom land.

This comment so obviously belongs on https://news.ycombinator.com/highlights that it's maybe a good occasion to mention that https://news.ycombinator.com/highlights exists. Thanks!

(and sorry for offtopicness)

Wow, no idea highlights existed. Glad you used this opportunity to …uhh… highlight it via this great post.

I was at MIT just before this switch, and treasure having gotten to take these deep dive courses, even if .002 and .003 kicked my ass.

6.004 (followed up by 6.033) is probably the course that really drove my career into systems dev.

Neat. Is there any way to search the highlights?

("What are the most noteworthy things that have been said on HN about ...?" "I remember reading an excellent comment that had something to do with ..., but all I can remember is that it used the word ..." "Do I have any comments in the highlights?")

Not yet, sorry.

Would love an RSS feed.

That would require ordering them by time highlighted, not by the original time posted. Worth doing, but not done yet!

ordering by time highlighted would be nice in any case, but actually, for an RSS feed it is less important. at least some rss clients can tell me which entries are new or updated regardless of the date.

MIT "units" of class divided by 3 = other American university credits. 3, 4, and 5 credits would be 9, 12 and 15 units; generally 15 units includes lab time, although there are more or less pure lab classes too.

credits are hours spent in class per week, and units are ostensibly hours of class plus homework, except it's a lie, there is much more homework than that.

Thanks for the history. I was an undergrad at the time and remember having a choice between 6.001 and 6.01. I don’t think I formally switched into course 6 yet and by the time I did, 6.01 was the only option.

> 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".

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.

> 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.

> 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.

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

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.

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.

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

> - 1 Building Abstractions with Procedures

Where Abelson, Sussman & Sussman use the word "procedures" here, they mean what we would typically call "functions" today. Today, "procedural programming" basically means "imperative programming", and that is not the idiom they are teaching. (Where the exact term "procedure" is used nowadays — though it's less common now — it generally refers specifically to a function which does not return a usable value, which is called specifically for its side effects. SICP instead generally describes what we would now call "functional programming".)

> 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

By "SICP" I clearly meant 6.001 and only 6.001, since that's the course titled as such ("SICP" stands for "Structure and Interpretation of Computer Programs").

I was not asserting that SICP was concerned with any term in the sense of the core material of any other course, which is why I didn't mention the other courses in that sentence. I was asserting that SICP was concerned with those concepts as they are commonly understood.

I wrote the comment knowing nothing of the content of the other courses, because nothing about the content of the other courses was relevant to the point I was making.

Please do not try to tell me what I meant by my own words.

> 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.

Kragen, I think you hit the nail on the head with this.

From the 1e Preface:

"Our design of this introductory computer-science subject reflects two major concerns. First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute."

And also,

"Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems."

6.001 germinated in 1978! There were far fewer languages to choose from then.[0] As elegant, and expressive, and powerful as Scheme is (being an attempt to strip a language down to the essentials), perhaps there just are more legible languages these days. A good exercise would be to go to Rosetta Code[1], pick a program, and compare the aesthetics of the code. What solutions are the cleanest and easiest to understand?

[0]: https://en.wikipedia.org/wiki/Timeline_of_programming_langua...

[1]: https://rosettacode.org/wiki/FizzBuzz#

Some notable examples:

(pulled from https://rosettacode.org/)

  --------------------------------
  [[ Scheme ]]
  
  (do ((i 1 (+ i 1)))
      ((> i 100))
      (display
        (cond ((= 0 (modulo i 15)) "FizzBuzz")
              ((= 0 (modulo i 3))  "Fizz")
              ((= 0 (modulo i 5))  "Buzz")
              (else                 i)))
      (newline))
  
  --------------------------------
  [[ Python ]]
  
  for i in range(1, 101):
      if i % 15 == 0:
          print("FizzBuzz")
      elif i % 3 == 0:
          print("Fizz")
      elif i % 5 == 0:
          print("Buzz")
      else:
          print(i)
  
  --------------------------------
  [[ Logo ]]
  
  to fizzbuzz :n
    output cond [ [[equal? 0 modulo :n 15] "FizzBuzz]
                  [[equal? 0 modulo :n  5] "Buzz]
                  [[equal? 0 modulo :n  3] "Fizz]
                  [else :n] ]
  end
  
  repeat 100 [print fizzbuzz #]
  
  --------------------------------
  [[ Racket ]]
  
  (for ([n (in-range 1 101)]) 
    (displayln 
      (match (gcd n 15) 
        [15 "fizzbuzz"] 
        [ 3 "fizz"] 
        [ 5 "buzz"] 
        [ _  n])))
  
  --------------------------------
  [[ Arc ]]
  
  (for n 1 100 
       (prn:check (string (when (multiple n 3) 'Fizz) 
                          (when (multiple n 5) 'Buzz)) 
                  ~empty n)) ; check created string not empty, else return n

  --------------------------------
  [[ Rust ]]
  
  fn main() {
      for i in 1..=100 {
          match (i % 3, i % 5) {
              (0, 0) => println!("fizzbuzz"),
              (0, _) => println!("fizz"),
              (_, 0) => println!("buzz"),
              (_, _) => println!("{}", i),
          }
      }
  }
  
  --------------------------------
  [[ Julia ]]
  
  for i in 1:100
      if i % 15 == 0
          println("FizzBuzz")
      elseif i % 3 == 0
          println("Fizz")
      elseif i % 5 == 0
          println("Buzz")
      else
          println(i)
      end
  end
  
  --------------------------------
  [[ Hy ]]
  
  (for [i (range 1 101)] (print (cond
    [(not (% i 15)) "FizzBuzz"]
    [(not (% i  5)) "Buzz"]
    [(not (% i  3)) "Fizz"]
    [True            i])))

  --------------------------------
  [[ Crystal ]]
  
  1.upto(100) do |v|
    p fizz_buzz(v)
  end

  def fizz_buzz(value)
    word = ""
    word += "fizz" if value % 3 == 0
    word += "buzz" if value % 5 == 0
    word += value.to_s if word.empty?
    word
  end
  
  --------------------------------
  [[ Perl ]]
  
  for my $i (1..100) {
      say $i % 15 == 0 ? "FizzBuzz"
        : $i %  3 == 0 ? "Fizz"
        : $i %  5 == 0 ? "Buzz"
        : $i;
  }
  
  --------------------------------
  [[ Ruby ]]
  
  1.upto(100) do |n|
    print "Fizz" if a = (n % 3).zero?
    print "Buzz" if b = (n % 5).zero?
    print n unless (a || b)
    puts
  end
  
  --------------------------------
  [[ Prolog ]]
  
  fizzbuzz(X) :- X mod 15 =:= 0, !, write('FizzBuzz').
  fizzbuzz(X) :- X mod  3 =:= 0, !, write('Fizz').
  fizzbuzz(X) :- X mod  5 =:= 0, !, write('Buzz').
  fizzbuzz(X) :- write(X).

  dofizzbuzz :-between(1, 100, X), fizzbuzz(X), nl, fail.
  dofizzbuzz.
  
  --------------------------------
  [[ Haskell ]]
  
  fizzbuzz :: Int -> String
  fizzbuzz x
    | f 15 = "FizzBuzz"
    | f  3 = "Fizz"
    | f  5 = "Buzz"
    | otherwise = show x
    where
      f = (0 ==) . rem x
  
  main :: IO ()
  main = mapM_ (putStrLn . fizzbuzz) [1 .. 100]
    
  --------------------------------
  [[ OCaml ]]
  
  let fizzbuzz i =
    match i mod 3, i mod 5 with
      0, 0 -> "FizzBuzz"
    | 0, _ -> "Fizz"
    | _, 0 -> "Buzz"
    | _    -> string_of_int i
   
  let _ =
    for i = 1 to 100 do print_endline (fizzbuzz i) done
    
  --------------------------------
  [[ Nix ]]
  
  let
    fizzbuzz = { x ? 1 }:
      ''
        ${if (mod x 15 == 0) then
          "FizzBuzz"
        else if (mod x 3 == 0) then
          "Fizz"
        else if (mod x 5 == 0) then
          "Buzz"
        else
          (toString x)}
      '' + (if (x < 100) then
        fizzbuzz { x = x + 1; } else "");
  in
  fizzbuzz { }
  
  --------------------------------
  [[ Elixir ]]
  
  1..100 |> Enum.map(fn i ->
    cond do
      rem(i,3\*5) == 0 -> "FizzBuzz"
      rem(i,3) == 0    -> "Fizz"
      rem(i,5) == 0    -> "Buzz"
      true             ->  i
    end
  end) |> Enum.each(fn i -> IO.puts i end)
  
  --------------------------------
  [[ J ]]
  
  (":[^:(0=#@])Fizz`Buzz;@#~0=3 5&|)"0>:i.100
  
  --------------------------------
  [[ Forth ]]
  
  : .fizzbuzz ( n -- )
    0 pad c!
    dup 3 mod 0= if s" Fizz" pad  place then
    dup 5 mod 0= if s" Buzz" pad +place then
    pad c@ if drop pad count type else . then ;
  
  : zz ( n -- )
    1+ 1 do i .fizzbuzz cr loop ;
  100 zz
  
  --------------------------------
  [[ Go ]]
  
  func main() {
      for i := 1; i <= 100; i++ {
          switch {
          case i%15==0:
              fmt.Println("FizzBuzz")
          case i%3==0:
              fmt.Println("Fizz")
          case i%5==0:
              fmt.Println("Buzz")
          default: 
              fmt.Println(i)
          }
      }
  }
  
  --------------------------------
  [[ C ]]
  
  int main (void)
  {
      int i;
      for (i = 1; i <= 100; i++)
      {
          if (!(i % 15))
              printf ("FizzBuzz");
          else if (!(i % 3))
              printf ("Fizz");
          else if (!(i % 5))
              printf ("Buzz");
          else
              printf ("%d", i);
  
          printf("\n");
      }
      return 0;
  }
  
  --------------------------------
  [[ Java ]]
  
  public class FizzBuzz {
      public static void main(String[] args) {
          for (int number = 1; number <= 100; number++) {
              if (number % 15 == 0) {
                  System.out.println("FizzBuzz");
              } else if (number % 3 == 0) {
                  System.out.println("Fizz");
              } else if (number % 5 == 0) {
                  System.out.println("Buzz");
              } else {
                  System.out.println(number);
              }
          }
      }
  }
  
  --------------------------------
  [[ Scala ]]
  
  object FizzBuzz extends App {
    1 to 100 foreach { n =>
      println((n % 3, n % 5) match {
        case (0, 0) => "FizzBuzz"
        case (0, _) => "Fizz"
        case (_, 0) => "Buzz"
        case  _     =>  n
      })
    }
  }

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...

Wizardry!

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.

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."

It's very "functional" in the "functional programming" sense, but not at all in the sense that 6.003 is about the "functional" descriptions of LTI systems (i.e., that the "signal" output of a "system" is a function of the input, which you can do things like take the Laplace transform of). "Procedural" is the term used in the class's textbook, and the "functions" in Scheme are called "procedures" in the Scheme standard.

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 the beauties of Scheme/Lisp (and source of much of its power) is the simplicity of the syntax. It allows it to be incredibly succinct.

The last section in the chapter builds a compiler to translate Scheme into this virtual machine assembly code so you can run it in the virtual machine simulator. An ouroboros.

SICP is a gem. Thank you Hal and Gerry!

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.

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)

A translation of:

  (define (factorial n)
    (if (= n 1) 
        1
        (* (factorial (- n 1)) n)))

It's quite a jump in knowledge, but explained very clearly through a series of guided examples. It's close to equivalent code in x86 or arm, but much easier to read.

"Programming Should Eat Itself" by Nada Amin https://www.youtube.com/watch?v=SrKj4hYic5A

The future of AI code generation?

https://neurosymbolic.metareflection.club/

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.

I appreciate it. The observation was really intended to be about the semantic drift, and the odd coincidence of language.

Thanks for this history, very interesting! I guess I can see the reasoning there, but as an Econ major who took 6.001 for fun, it makes me a little sad. That class was mindbending and so interesting.

Hi Keith! Another consideration was that the core computer programming skills needed to be taught more broadly to basically everyone and not just course 6 students.

Source: I shared an office with Keith next to Hal and Gerry--he taught me Java! Fun anecdote: we had to move RMS's stuff to the new CSAIL building because he had broken his arm punching a wall.

Ive broken my hand punching a wall, its not nice :/. Also I hated scheme in first year uni, my brain just did not get the pattern matching required... Australian uni's probably just copied the syllabus from US ones at that time.

I misremembered the story and checked on details: the arm broke in a fall while he was travelling several months prior to the move and it was Gerry joking that he punched a wall so he wouldn't have to move stuff.

A useful reminder that economics plays as much, if not more import in what is taught and how it is taught, as any pedagogical drive. If attendance drops, universities can pivot. Gotta get the bums on seats.

20 years ago Cisco came shopping in Australia for ee grads who could do microcode. The US degree mills had stopped teaching students how to code an edge case for most jobs, and the router and switch vendor had to find places who still did that.

It's interesting that you would name Cisco. They hired Kent Dybvig and acquired Cadence Research Center in 2011 for Chez Scheme[0] — possibly for use in processing IOS configs, testing, and network management. It seems like Chez was the most performant scheme in the day[1] and was proprietary, expensive, and possibly not available to individuals.[2]

There were a number of good free schemes[3], and Chez was open-sourced in 2016, but I wonder how much of Perl, Ruby, and Python's popularity derived from their open licenses.

[0]: https://web.archive.org/web/20241107091603/http://community....

[1]: https://web.archive.org/web/20180917033028/https://ecraven.g...

[2]: http://www.cs.cmu.edu/Groups/AI/html/faqs/lang/scheme/part2/...

[3]: http://www.cs.cmu.edu/Groups/AI/html/faqs/lang/scheme/part2/...

The Development of Chez Scheme R. Kent Dybvig

https://web.archive.org/web/20061205234158/https://www.cs.in...

The Scheme Programming Language 4e

https://www.scheme.com/tspl4/

"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.

"it was all data/signal flow and intercoupled and layered differential equations from sensors to actuators anyways."

And the you need a pure CS dude like me to turn that into readable, maintainable, efficient code.

(I work with these guys who just see the differential equations... Leave them a few years on their own and they produce a huge pile of code and then wonder why none of the students use it :-)

(it's just my own experience, and although I'm a bit cynical here, I like that job and these guys a lot, we learn a lot from each other)

But the industry standard in those times (and still) is to use the graphical-only world of Matlab Simulink, so you cannot make any syntax, type and API errors. Thanksfully MIT decided against that.

>the department has largely deprecated the idea of an EECS core curriculum

From my perspective, a tragedy.

https://www.codeandcoffee.dev/

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...

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.

Yes. One of the biggest complaints that computer science departments used to get from students is that they weren't learning any languages that employers are using.

I'm not so sure someone who's good with Scheme will be bad with Python or Java.

On the contrary, I suspect that such a person is likely to be better suited to build software in either of the latter two.

I also suspect that Python is not a particularly good first language for someone who aims for a professional career building software.

> I'm not so sure someone who's good with Scheme will be bad with Python or Java.

The problem likely has always been the companies / HR rather than the students.

> I also suspect that Python is not a particularly good first language for someone who aims for a professional career building software.

It's not a particularly bad one either, certainly better than Java.

IIRC a secondary benefit is that it allows overlap between some of the basic CS, and the CS/CE courses for non CS track students

> I'm not so sure someone who's good with Scheme will be bad with Python or Java.

They won't be. But students don't understand that, they want to learn marketable skills and are 18 years old. They haven't figured out that if your skills transcend language choice you will be more marketable even if it means you have to spend a few weeks learning a new language for a new job. They lack maturity, which isn't surprising given their age and experience, and so they complain.

When I went to university in the 90's, Scheme was used in a couple of early courses. I had already learned C and Java on my own, but greatly enjoyed how Scheme made me think about problems differently. (I didn't learn Python until much later when I was out of school.)

As long as students are exposed to multiple languages, I think starting w/Python is fine. Every language has its issues.

There were plenty of less rarefied CS departments that were concerned about this, and they taught C, C++, or Java in their introductory classes.

Ultimately, it doesn't matter. It's your first language, not your last.

How many people do you know who are monolingual?

Only knowing the language you were required to know to pass a bunch of tests when you were 18 is a negative signal.

If someone is interviewing and they only have Java listed, and their school is known for teaching Java for their introductory classes. They're probably not that strong of a programmer.

Human languages and programming languages are not comparable. You will need a lot more effort to become fluent in a second human language than in second programming language. Even if the human language is Esperanto (designed to be really easy for speakers of European languages), and the programming language is C++ (perhaps the most inconsistencies and foot guns) the programming language will need a lot less effort to learn to a high level.

Multiple computer languages are probably more like learning vocabulary in different domains of life and learning to write for different media.

They're not directly comparable because humans have an inbuilt ability to learn human languages.

The vast majority of people on the planet know more than one human language and know zero computer languages. It's literally the opposite of what you're claiming.

That's very superficial and wrong.

It makes a huge difference, whether you have to learn thousands of new words, irregular grammar and (after learning thousands of concepts in the first language) learning a few hundred new concepts, or you learn a computer-understandable language, that has maybe, if very inelegant, 100 keywords, and 100 concepts, most of which you will probably not use often.

Compared to these numbers, the fact, that something is a natural language, has very little influence on the outcome. It is the sheer effort needed to learn a natural language, that makes the difference.

They’re not directly comparable because programming languages are much simpler and much easier to learn. Becoming a good programmer is hard, but that’s not due to difficulty of learning a programming language. Once you’re a good programmer, new languages are easy. A decent programmer should be able to do something useful in a new language in a week or less, and be reasonably competent in a month or two. See how long it takes anyone to learn a human language to that level.

> Once you’re a good programmer, new languages are easy.

Not always. Languages can differ radically. If the new language uses concepts you've never encountered before, you're going to need to do the work of learning those new concepts.

An example I've used before: 20 years writing C code for embedded systems won't give you any insight into Haskell's applicatives or monads.

I bet that C programmer will still learn Haskell way faster than someone with no programming experience, and way faster than just about anyone will learn a human language.

Learning to program may be hard, but learning programming languages is relatively very easy. In other words, your second programming language is so much easier to learn then your first was.

I regularly use several programming languages, and tend to pick up a new one every year. I've been spending the last six months studying my second spoken language; I promise you human languages are much harder to learn.

Have you thought through what you said?

You also have an inbuilt ability to learn a computer language. What even is an inbuilt ability?

Programming languages are something you read and write and execute. You can learn many and their definition is precise and limited. It's very easy to be able to pick a programming language and use it in relative low amount of time.

Human languages are absolutely different. You can't easily pick them up and they carry cultural context, regional variations, and a lot of ambiguity and history. Definitions of those languages tend to be complete or prescriptive but descriptive and evolving. The languages are written, spoken, read and listened to. The variation in all of those is immense.

Do you acknowledge any of this or will you double down in the most absurd of points?

having actually learned esperanto and become a fluent speaker in just half a year, i am not so sure. esperanto grammar is trivially easy compared to any other language (the rules fit on a postcard in regular sized print), but if you'd take any other language, i'd agree.

programmers, and good ones imo, are almost always polyglots on some level, and i tend to think have a better than average ability to even pick up natural languages.

programming languages have a small, manageable and finite set of vocabulary, idioms, and constructs that most languages share but express differently depending on their intended use. a programmer fluent in programming will be able to pick up most languages. how those pieces are cobbled together to form more complicated abstractions becomes the skill obv.

that does not mean they'll be an expert right away, but it does mean they are usually competent enough at minimum to dive in and work with it just like any other tool -- they know they'll need a screwdriver, maybe a hammer, so they look up what it looks like and how it is used.

my daily drivers are python, cmake/Makefiles, c++, and c, with a sprinkling of bash, powershell.

i've worked with microsoft stacks C#/SQL, JavaScript, and i've written a ton of Lua. i've studied concepts and swe fundamentals in languages i don't really write code in and transcribe into code i do intend to write code in. i learned mostly using Lua first, then i picked up c++.

these are just the tools of my job overall. my main skill is communication and learning imo, and knowing which tools are better suited for a task at hand depending on requirements and limitations (mine or technical or both).

I learned programming before entering a degree in this stuff and I think learning a badly designed language as first language made me lose a few years, and additionally, if I weren't so driven to learn more, I probably still wouldn't know more than many others, and might have never explored the field of functional languages. If I hadn't started reading SICP and exploring Scheme and others, I wouldn't know half of what I know now about computer programming.

Sticking to only some Algol family language makes people have a severely limited perspective on things.

To be fair, if you learn computer science well enough to thoroughly understand Scheme, I don't think it'll take more than a few weeks during the summer to learn Python.

I disagree. You can learn the language itself pretty quickly. Finding your way through the expansive standard library will take longer. Getting a good handle on the package ecosystem is a lifetime learning project.

Knowing your way around the ecosystem of one programming language does not build up the intuition necessary for identifying O(n²) (or worse!) algorithms and choosing/writing O(log(n)) (or better!) ones instead.

Computer Science has little to do with science, but what it teaches you is certainly closer to science than just building a huge mental index for a bunch of work done by other people.

There's certainly value in that skill, but it has no place in a Computer Science curriculum.

This would be like taking Astrophysics students and telling them to study the details of all of the different kinds of telescopes they can buy.

That's not really what we were talking about here. The context was that compsci students want to learn marketable skills, and the claim was that if the student had learned Scheme in class, they could quickly pick up Python. And that's true, for the language itself. But knowing only the language, like never importing code you hadn't written yourself, doesn't go far along the road to marketability.

I'm not arguing that compsci should be job training, not at all. My disagreement is solely with this specific claim.

But FWIW, while I understand your analogy, an astrophysics department that didn't tell the students that there are these things called telescopes, and here's why you might use one over the other for various situations, and that they're how you're going to get the observation data you'll test your theories against, would be doing a disservice.

> Knowing your way around the ecosystem of one programming language does not build up the intuition necessary for identifying O(n²) (or worse!) algorithms and choosing/writing O(log(n)) (or better!) ones instead.

I'll disagree with this, at least in terms of Scheme versus Python.

Python is visually close enough to other languages that the skills you develop to quickly see O(n²) algorithms easily transfer to many other languages. Scheme is very different visually, and so the intuition doesn't transfer as well. Sure, it's possible your intuition is wrong, but when scanning a program intuition can help in the first pass.

Scheme has (trace), at least most interpreters (and his cousing Common Lisp) have some tracing and pretty-printing features. Far more powerful than anything Python could offer.

Oh, and of course it has functions like sdraw or draw-cons-tree when you can print the contents of a list in seconds as an ASCII-ART chart:

https://www.t3x.org/s9fes/draw-tree.scm.html

The file it's in the public domain.

Try that with Python.

Python has the pprint module, which takes care of this for you, and for more datatypes than are done here. (I don't see how this would handle a hashmap in a sensible way.)

But I'm not sure how this addresses what I was saying, which is that the intuitions about algorithms you get working on Python are easier to transfer to popular languages like C++, Java, Javascript, Rust, etc..

You can learn about algorithmic complexity in python. Why not just focus on one language to keep things more focused.

Those are things though, that you can easily make up for, for the most part, with good web search skills, or these days, AI prompting skills.

This depth you are never going to get in a college education anyway. Especially not since programming isn't (and shouldn't be) the only thing you learn in a Software Engineering / Computer Science bachelor.

One of the big shifts in academia over the past couple decades is that, for any number of reasons, students today are less likely to self-study or tinker outside of classes and internships. The increased prevalence of basic bootcamp-style classes like "Let's Build a Rails App" in CS programs is because departments can no longer assume that students will explore things like that in their spare time.

What good does that do, though? Make it harder to tell the intrinsically motivated students from the “I’m just here to get a job when I graduate”? It seems like it harms the former.

Is that what we need from universities? Is that helping employers? Helping strong or intermediate students?

It's what universities have become. They are expensive, grandiose trade schools operating out of very distinguished-looking Collegiate Gothic designed buildings.

I always found this to be a shortsighted complaint. Getting exposed to languages where computation models are clear gives you an excellent background to switch to the language du jour and become a master. Going through e.g. HtDP or CTM makes it easy to transition to Python and write excellent code, whereas traversing the opposite path is going to be tough.

I agree, but those don't need to be the languages you use in all classes. I learned a few assembly and academic languages (MIPS and LISP) in classes for those two topics, and it was absolutely useful to learn how to think in terms of those languages. The vast majority of our classes were Java though, and that's also been the vast majority of what I've done since graduation. (I think my school has since moved to Python as well)

So I graduated with that really helpful knowledge about why modern languages work how they do, but also a lot of practical experience of actually using those modern languages too.

even better is learning the languages you want to learn

why are you paying a school to teach you something adjacent to what you want to learn so you can learn the thing you need yourself?

> why are you paying a school to teach you something adjacent to what you want to learn so you can learn the thing you need yourself?

Because some topics are easy to learn by yourself, and some are not, so the latter ones are better learned in a college setting.

Learning a language definitely belongs in the first category. Learning computer science goes in the latter category.

I don't agree with that. I think Python is a better first language. The better students will get through the program just fine, especially if they really want to learn computer science in depth. And the average ones will at least learn something useful.

If you understand the fundamentals, you can easily switch between languages.

Sure, it's possible to catch up, but we're talking about at least four years of potential experience. That means spending years catching up, which can seriously impact you career.

Not a unique problem to software either. My sister in-law is a mechanical engineer. Her first employer was upset she didn't know anything practical, and only knew theory. She had to spend years catching up.

Some technical universities in EU solve this problem by having full-time practical courses e.g. in January and June. For example, as a CS freshman you can build a really solid background in functional programming by going through a sequence of SML or Haskell courses in Autumn and Spring and spend January and June learning trendy technologies in depth. It's the best from both worlds.

Having taking a course based on HtDP as my first serious coding course in college, it was good at teaching many concepts, but it felt very verbose and was aggressive in its hiding of features that weren't that difficult to grasp.

I always found scheme to be a clean slate where no one’s high school experience benefited them in the first year.

My program did Java for the second course, which was very popular in industry and I loathed it.

I do think Python is not so bad to standardize on because it’s stood the test of time and is one of the most popular ways to write code for many disciplines and has applications outside of computer science so it helps everyone that takes the cs requirement even if they aren’t a cs major.

What im saying is Python can even serve as a better version of spreadsheets for folks that aren’t cs.

I think someone who learns computer science well from the theoretical side can pick up a new language quickly. After all, if it's turing complete, it's turing complete, they're all the same at that level.

Problems creep in when the person doesn't learn CS well, chooses an approach that is deeply reliant on overly complex/opaque libraries without good documentation, or the like.

That's kind of a useless argument. Universities often also don't teach people any web development. In many cases a graduating student has never worked on any real project. If the university's idea is, that the student can learn those things in their free time, then surely asking someone to learn a little bit of Python or another language is not too big an ask either. So which one is it? Learn that stuff at home on your own time, or university should teach it, because it is needed on the job? Then what other things are they not teaching that is used on the job?

When I was in college, we had our base software development courses and could choose web development as an elective. Our class taught .NET.

indeed. The problem with being expose do to something so much more clean/elegant/powerful than the languages employers are using is that you no longer want to do it. It's like having tasted good whisky. You no longer think Jack's acceptable.

These days, employers more or less get what they wanted. We're doomed.

Executable pseudocode is an oxymoron.

And so is Python in many ways. The shoe fits.

An oxymoron is a word or phrase that contradicts itself (the word comes from Greek bits meaning "sharp" and "soft"). It doesn't make any sense at all to say that Python is an oxymoron. Python-the-language isn't the kind of thing that can be an oxymoron; "Python"-the-name obviously isn't one because it doesn't have two parts that could contradict one another.

Does your comment mean anything other than "I don't like Python very much", and if so what?

"essentially", come now.

The point is that python's syntax reads a lot more plainly and logically for learning than something like Java.

I am confused, what is the relevance of the word essentially?

Do you agree or disagree that Python is more readable/closer to pseudocode than say Java or C++? Less syntactic sugar, no need to define namespaces/classes, more intuitive for declarations, etc.

Would you consider essentially dry water to be semantically correct phrase?

I understood the meaning of their phrase and explained it. You assert that the original phrase is incomprehensible and meaningless. We see things differently.

Are functional languages more computer science than imperative languages?

Formal reasoning about functional programs in terms of their (denotational) semantics is normal in a functional programming class (e.g. it's about a quarter of our mandatory-for-undergrads FP course).

Formal reasoning about imperative programs in terms of their (e.g. axiomatic) semantics is only in a grad-level course, and the programs you can reason about are really, really limited compared to the functional ones. (The last time I TA'd the FP class, one of the homeworks involved proving a simple compiler correct. When I took the grad course, I think the most complicated program we proved correct was selection sort.)

I think "reasoning about programs" is more computer-science than "writing programs," and choosing an imperative language signals that you're not emphasizing the former.

It's one way of modelling the broad notion an algorithm, but it isn't the only one, and it's odd to treat it as the one true expression of computer science when essentially all modern computing follows a different model.

Lambda Calculus is one of those things that look good on paper as a theory construct but in practice it's not a great abstraction.

And honestly you could go your whole career without touching it, maybe only for the naming of an anonymous function.

Boolean logic, graphs, FSMs, set theory, mathematical proofs, pretty much all user here or there. Lambda calculus? Unless you're one of those Haskell fans, meh.

> Haskell

https://book.realworldhaskell.org/

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.

> LISP dialects like Scheme are excellent for teaching pure computer science because they are the closest thing to executing lambda calculus expressions.

Assembler too. For example, Knuth's [M]MIX in The Art of Computer Programming.

That said, this is an introductory programming course, and there are separate courses focused on algorithms (which are not the same as programming). I agree with the article: programming has changed dramatically, while the core of algorithms remains largely unchanged.

> the more general trend of colleges becoming more vocational

Things would be so much better if this were actually true..

Colleges becoming more vocational is a consequence of colleges becoming more expensive for students. If you are paying all of that money for college, you better get a good job out of it. I don't see that as a bad thing necessarily, but it would definitely be nice if we had better paths for those who want to end up in research.

I'd argue that SML (or derivative thereof) would make for a better teaching language, for both the lambda calculus aspect and the type theory aspect.

> I'd argue that SML (or derivative thereof) would make for a better teaching language, for both the lambda calculus aspect and the type theory aspect.

https://news.ycombinator.com/item?id=13098598

A critique along those lines which suggests KRC and Miranda which are in the same vein as SML.

I suspect you might be observing two correlates and picking one as the cause of the other in a way that is ahistorical.

Specifically, it seems to me that colleges becoming more vocational and colleges becoming more expensive are both natural outcomes of the neoliberalisation of all things. I am aware that some students now rationalise their educational investments with the logic you describe above, but I think it's a post-hoc rationalisation.

You can get a good job without going to college, and you can get a good education without paying a gazillion bucks.

A side point, but calling it "vocational" seems a bit euphemistic too. Learning carpentry is a vocation. Getting a business degree is not equivalent to learning carpentry. I might say colleges have become commercialised, rather.

I attribute the curriculum shift to something slightly different, which is the changing perception of CS as a career.

When I was in college in the late 1980s, CS was not perceived as the moneymaking career it is today. Accordingly the kids who went into CS were typically the nerds and hackers who truly loved the field.

Many kids now perceive CS as a safe, lucrative career option akin to becoming a doctor or lawyer. It attracts many students who are smart but perhaps not as intrinsically excited about the field. The universities adjusted their curricula to what these students care about: Less beautiful theory, and more practical training.

A similar thing happened in statistics. At one time it was hardcore stats nerds. Now "data science" has brought a ton more people into the field and the teaching methods have changed dramatically.

College becoming more vocatioanl is a consequence of colleges becoming more accessible to a much larger population, beyond the already wealthy.

Community colleges are the cheapest colleges, yet the most vocational.

The most expensive colleges are the Liberal Arts Colleges and the Ivy League, which are the least vocational.

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. Widely used tools and practices offer a flywheel of usefulness that can help motivate undergrads to learn about computation. Once you learn Scheme, well now you've learned Scheme. But at the time if you had learned Python you could then use something like Python's system and socket APIs to play around with the lab or personal Linux systems. On the web side, there was web.py or Flask (haha this was the late 2000s/early 2010s) to motivate yourself to keep going. The student could spend their summer building apps and tools so that they appreciate computation for more than just its "aesthetic" beauty.

This was a time when CS wasn't all that prestigious on its own and salaries weren't as high as they are now, so many folks who banged their head against Scheme or MMIX or LC3 would just churn to the EE or MechE departments.

2. As a grad student it was almost trivial to set an exam paper that could weed out most of the class. This was especially trivial at the introductory class level where Scheme would be taught. If the concern was rigor it was very simple to maintain the rigor in other ways.

3. For better or for worse many undergrads had no intent of going to grad school, and many of the undergrads taking our classes weren't even students of computer science. They were electrical engineers or industrial engineers who wanted to learn enough programming to automate things in their field but were more interested in their actual areas of concentration.

In the years since my thinking around this evolved, but I still share the same conviction I did then. Probably moreso given the sheer ubiquity of Python now.

help motivate undergrads to learn about computation. Once you learn Scheme, well now you've learned Scheme. But at the time if you had learned Python you could then use something like Python's system and socket APIs to play around with the lab or personal Linux systems

that's a good point actually. i had scheme, modula and others i don't remember in my undergrad classes. i remember almost nothing from that time. but at the same time i met some students running an LPmud, where i learned LPC, and then i discovered roxen and pike (which is based on LPC) which i used in all my volunteer and fun programming work. in other words all my motivation for learning stuff came from the outside.

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 "data science" or the like. Undeniably most prospective CS students are not aiming to go into academia, but we shouldn't adapt to this majority and then leave behind those who do want to do more academic things.

My background is in physics, where this sort of dual-track curriculum is well-established, and the physics taught to physics majors is very different from that taught to engineers. Unfortunately the difference is often boiled down to rigor or difficulty (and this will be reinforced if it's physics professors that have to teach both of the tracks), but in reality it is a value-neutral split which is based on pragmatism. CS should have one too.

We did end up making this switch later on due to growing class sizes anyway. That certainly helps focusing the class. We ended up focusing on computation more for the CS sequence and on the nuts and bolts of getting a program working for the non-CS sequeunce.

But my rationale for moving to Python still stands. In fact, I know several brilliant ML researchers who write code that would never come close to making it to production. The things we optimize for are different. Production code in a tech company needs to be readable, maintainable, explainable, and scalable. An ML researcher's code needs to support their research. These different perspectives are still why I think focusing on a wider appeal language like Python over something like Scheme still makes sense.

FWIW our CS program mandated a programming languages class and the first third of the class was taught in Scheme.

>FWIW our CS program mandated a programming languages class and the first third of the class was taught in Scheme.

This is important but doesn't replace having a dual-track intro sequence. The reason one has "physics for physics majors" isn't because physics majors need to learn some of this complicated stuff ASAP. They definitely don't, and I don't doubt students in the program will eventually get a well-rounded education. But it's a good idea to give incoming students a taste of what the field is like as soon as possible, so they can see if they like it or not. (Essentially it's a "weeder", but for the students' sake so they can self-select on interest and not just instructional staff's sake of being elitist.) Probably some (but not all) professors/postdocs/grad students would scramble to teach the more advanced sequence as it is likely more engaging for them than the current intro curriculum.

To be clear I don't think an advanced intro CS can't be in Python on principle, but such a class probably introduces multiple languages to some degree: they could be toy assembly languages or real ones in addition to the majority of the course content in Python.

Brown CS actually does this! Accelerated Intro to CS is taught in Racket, I believe.

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).

I could never understand the proof allergy. To be honest I find it was easier for me to perform well in proof based classes rather than “here’s an algorithm, apply it” type. The main reason was that it was harder for me to make mistakes while constructing a proof in comparison to applying an algorithm and making calculations by hand.

I acknowledge high schools are notorious in omitting the introduction to proof techniques but it’s a one time hurdle and you end up with a good stuff in your toolbox.

>Once you learn Scheme, well now you've learned Scheme.

There is something really joyful in learning a new language and then implementing a well-known protocol, like HTTP, in that language. You can pick either the agent or server side, and check your work with other well-known agents and servers. In my experience this tends to happen when students like the language they've just learned, regardless of the direction their given by staff. In fact, I'd almost consider it definitional of what it means to like a language - that you'd consider implementing a well-known protocol in it in your free time.

> There is something really joyful in learning a new language and then implementing a well-known protocol, like HTTP, in that language.

That's probably the minority of students though

Maybe this is due to my interests (I specialized and published in distributed systems) but it's always been the opposite for me. Implementing HTTP/1.0 or IRC clients is one of my favorite ways to learn a new language (albeit it's a bit heavy on the IO which can be unfair to functional languages that model effects.) My interest in network software is that I can standup the software and have it participate in the network immediately. It's the application that leads me to appreciate the language not the other way around. My interests in theorem proving and program verification came from debugging heisenbugs in the wild and wasn't motivated by the algorithmic complexity or mathematic sympathy.

But I dabbled in PLT in my grad days and have no doubt that there are folks who have your mindset as well.

The only point I really have an issue with is #2, where the focus seems to be on “weeding out” students as a sign of rigor. I would much prefer that some kind of pedagogical motivation replace this point.

Edit: I take that back.

> Once you learn Scheme, well now you've learned Scheme.

(Not from SICP but How to Design Programs): The claim is that you’ve learned how to THINK about programming. You understand how to organize and test your code so you can make a larger project.

I think the dismissal of a Scheme-like language as a dead end is shallow, and includes a large assumption about the (lack of an) ecosystem of the language. I think saying more will turn this into a rant.

"Computer engineering" isn't vocational. It's an entire sub-specialty involving hardware theory and application. "Programming" is the vocational shift which was traditionally outside the purview of academic curricula. You're not engineering anything if you don't have a repeatable process that will deliver expected results. Programming alone doesn't meet that bar.

I just completed the WGU Masters in "Computer Science".

I put the scare quotes around "Computer Science", because outside of a single algorithms and data structure course and a single AI course (which was extremely high level), it was purely engineering stuff. One assignment had me deploying stuff with AWS, I was designing wireframes of potential "apps" I could create, and I had to write one HTTP server.

It was kind of fun and it was nice that I was able to complete it quickly, but it really shouldn't be called "Computer Science", it should be called Software Engineering. There's nothing wrong with software engineering, I just view it as distinct-but-related from CS.

> Isn't this just part of the broader trend of CS departments switching away from teaching computer science to teaching computer engineering

Computer engineering is similar as hard as computer science (don't start the discussion which one is harder ;-) ). What CS departments instead switch to is teaching some shallow, applied programming knowledge.

I think it's absurd to start with Scheme. A graduate who knows Python but not Scheme has a hope of doing something with computer science. A graduate who knows Scheme but not Python is basically unable to use computers at a technical level. The only choices here are "Python" or "Scheme + Python".

(Yes, of course, they could teach themselves Python at that point---but if we're talking about things that people can teach themselves, they can teach themselves the whole curriculum and both languages; the debate here is over what the university should hold them accountable to learn).

> I think it's absurd to start with Scheme. A graduate who knows Python but not Scheme has a hope of doing something with computer science. A graduate who knows Scheme but not Python is basically unable to use computers at a technical level.

What language you start with and what languages you know on graduating are going to be different. It takes 4 years to get through most bachelors programs (without taking summer terms, very high course loads, or coming in with a bunch of transfer credits). It's no more absurd to start with Scheme than to start with Python when there are at least 7 semesters remaining to learn more.

If a graduate only knows what they learned in CS 1, they aren't a CS graduate even if they got that slip of paper. They conned the school, or the school conned them.

It's easier to explore deeper concepts learning with scheme because the language is such a simple and introspective encapsulation of generalized computer science concepts.

I and about a million other programmers started with BASIC. My second language was Pascal. I don’t imagine I’d be very employable if that’s all I knew, but it turns out that you can learn many programming languages and it’s not all that much effort after the first two or three. There’s no reason to think the language you start with should be one that you could get paid to use.

And no, I wouldn’t recommend starting with BASIC. But starting with Scheme seems like a great choice.

BASIC has a thriving hobby scene and there were compilers available for many platforms even if they weren't for "serious" computers. Scheme by comparison has essentially no community.

> it’s not all that much effort after the first two or three. There’s no reason to think the language you start with should be one that you could get paid to use.

Definitely!

This inspired me to list out languages I've learned to at least some minimal level and written programs in. Here they are, with the contexts in which I used them:

BASIC - middle school ;

Fortran - high school ;

C++ - self-taught & later some work;

Pascal - university;

Motorola 68k assembly - university;

Miranda - university (Programming Languages class only);

Ada - university (Programming Languages class only);

Lisp - university & work (CLOS);

sh - work;

ColdFusion - work;

bash - work and personal;

Java - work;

Atmel microcontroller assembly - hobby;

C - hobby (to replace Atmel assembly);

Ruby - work and hobby;

Scala - work;

Elixir - work;

Solidity - work;

Typescript - work and hobby;

Elm - work;

Clojure - work;

Javascript - work;

Python - hobby (with a tiny smattering of work usage over the years)

I think it is absurd to fail to learn the basics and focusing on 'deliverables' from day one.

You need to get the ideas first. The language used is the least of your concerns.

This is even more poignant on this era of vibe coding.

> most common language a computer engineer

Depends on your definition of a computer engineer. Dealing with strings in Python vs. dealing with character arrays in C is a world of a difference.

The decision to use Python feels like a solid compromise between giving the students a stair step to applied computer science work, while stripping away the cruft and language-specifics that would distract from implementing the more theoretical learning material

Depends on which part of the theory you care about. Lists in Python are a magic structure that can grow and shrink at will. That's a bit too high level to be useful for learning the theory.

I think you mean software engineering. Computer engineering is computing hardware, CPUs, etc.

I took Scheme for my second programming course, after C++. I think Scheme is simpler to understand. It also allowed students to explore various concepts that weren't available in C++. I enjoy the course.

But since I never took compiler theories and other courses on programming language, I never bumped into many of those concepts again except for those where modern languages adopted the same feature, and I ended up having to relearn them anyway. Hence, I would also argue that these days, most students would have been better served starting with a practical language.

> 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 Baby Python subset of the language that's just as simple and rigorously defined as Scheme and teach that, but this isn't how the new MIT intro courses have been designed.

Python was invented as a language for newbies. It's come a long way!

https://en.wikipedia.org/wiki/History_of_Python#Version_1

> During Van Rossum's stay at CNRI, he launched the Computer Programming for Everybody (CP4E) initiative, intending to make programming more accessible to more people, with a basic "literacy" in programming languages, similar to the basic English literacy and mathematics skills required by most employers. Python served a central role in this: because of its focus on clean syntax, it was already suitable, and CP4E's goals bore similarities to its predecessor, ABC.

https://en.wikipedia.org/wiki/ABC_(programming_language)

> It is intended for teaching or prototyping

It was an attempt but a bad one.

> "Python was invented as a language for newbies."

Yeah, but so was BASIC. If Edsger Dijkstra were alive today to write an updated edition of his infamous "How Do We Tell Truths That Might Hurt?" essay, he'd probably just just reuse his quip for BASIC for Python.

> 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.

I had a Twitter exchange with the author a few days ago on these topics.

My approach is to do what pyret was trying to do while maintaining the python syntax (with minimal deviation where necessary).

Making Python look more like Rust has a lot of support and could correct some of the his historical "injustice" :)

Because of the strong support for keeping python as an approachable imperative language, this will unfortunately require forking.

> Whereas Python is excellent for teaching applied computer engineering, because it's essentially executable pseudocode for imperative languages

Python offers quite good multi-paradigm support and could absolutely be used to explore many key concepts from SICP (granted, nothing is as meta-programmable as the Lisp family, since AST manipulation in other languages requires additional steps to actually obtain an AST). In particular, since Python's object model includes functions, higher-order functions are possible (and indeed, `map` is a builtin, and `reduce` is in the standard library after previous demotion from builtin status). Nowadays of course it's fashionable to litter the code with manifest type hints, which are a distraction to that sort of pedagogy. However, they are still entirely optional, have zero-to-generally-irrelevant effect at runtime, and can simply be disregarded.

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!

> turns out the entire scheme specification is short enough to fit on a double sided page if condensed

I think this only held for R4RS and earlier. You can fit War and Peace on one page if you condense it enough.

>You can fit War and Peace on one page if you condense it enough.

"I took a course in speed reading, learning to read straight down the middle of the page, and I was able to go through War and Peace in 20 minutes. It's about Russia." —Woody Allen

I worked an MIT programmer who bragged about the Scheme curriculum. He was also the worst programmer that I’ve worked with. He really liked clojure and would constantly complain about Python syntax, and ended up quitting abruptly when his hand spun Datomic based system was rejected.

I think there is a trap in thinking that a strange way of being taught puts one at an advantage. It is really annoying to work with people who believe they are more enlightened than others.

That kinda defeats the purpose of why scheme was the language of choice in the first place! The goal was for us to fall in love with programming, not a programming language.

Every person I know who has studied SICP is a tremendous programmer.

In my working life I've literally never had the chance to program in a functional language...it's been 90% Python for me. And I mostly love it. Though I do remember when first learning Python I was bummed out how limited the Python `lambda` is.

Gosh, I even got to work with the Python BDFL for a couple years. I'm no Scheme zealot!

The last sentence was the key:

    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.

I agree. I was taught Scheme and I later taught it. It was a much cleaner and suitable language for teaching computer science than Python. Students could completely understand the language and how it worked by the end of a semester.

Scheme is much closer to mathematics, which made it much more suitable for teaching strong mathematicians arriving without coding experience. It also made the hackers more rigorous and broadened their minds from the imperative "do this then that" mindset.

There's a notable difference between those first taught scheme and those first taught Python. Of course, both can go on to learning Python or FP or whatever. But that foundation needs to be there to teach truly great coding for most mortals.

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).

It is possible that this doesn't work anymore.

I distinctly recall the following episode when I last taught intro CS in Scheme: I revealed first-class functions. After lecture, the brightest kid in class came up to me and said something to the effect of, "What's the big deal? You can do this in Python."

That should be the beginning of the formative experience for that kid rather than the end. Yes, you can. How often do you? What are you missing by not thinking about problems in that way more often? What idioms could be unlocked that way? (How many Python programmers out there are aping wholly unnecessary "design patterns" created for C++ or Java? Or rather: shouldn't a design pattern be about the design rather than the implementation? What is a design, in the pure abstract, really?)

Don’t worry, aforementioned kid is doing just fine, machine learning PhD IIRC. There is a lot of other remarkable stuff in modern computing.

Oh, I don't doubt that. Smart kids usually land on their feet just fine (and even when they don't, they cope and mask their problems better). But when I get the opportunity to teach things, I strive to allow smart students to rise to their own level.

>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 also well remember the epiphany I felt while learning Logo in elementary school, at the moment I understood what recursion is. I don't think the fact that the language I have mostly written code in in recent years is Emacs Lisp is unrelated to the above moment.

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.

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.

But this is the problem. Our premier academic institutions shouldn’t merely exist as job training programs for big tech.

If anything, tech is still one of the better off fields in the university.

Look at history or literature programs for where this is heading. I’d imagine that most literature majors don’t even read at all these days. As recent as 50 years ago, the requirement involved hundreds of pages of reading per week, over a sustained 4 year period.

Honestly, just close down the university at this point, if all it wants to do is print out degree certificates for social signaling in the job market.

oldpersonintx2, your account is shadowbanned.

Which colleges did you send your kids to, what kind of degrees (just bachelors? undergrad and grad?), and how many kids?

The $800k figure without that context tells us nothing. If that's for 2 kids to get a BA/BS/BE, you got ripped off. If it's for 4 or 5 kids it makes much more sense when examining current costs.

I learned so much about computer science by doing my intro course in Scheme. Concepts that have helped me throughout my career. Concepts that I feel just cannot be expressed or understood nearly as well with Python (and I love Python, almost all my professional and personal coding is in Python).

Related. Others?

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)

> 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.

Absolutely agreed. This situation reminds me of discourse on learning natural languages, where people are constantly told that there is no substitute for time spent deliberately on immersion. But you won't accurately figure out grammatical structures that way; you'll get distracted by the parts you understand and fail to assemble them into a whole.

University (and earlier!) courses ought to focus on the kinds of things that actually require direction to learn.

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.

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.

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.

Can you not see that there is a philosophical difference between these two approaches and why someone might have a preference for one or the other?

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's a failed language family. Outside of academic life support and very niche uses (which are usually directly caused by the academic uses, such as Emacs lisp) scheme just doesn't exist out in the world, despite a dozen very competent and complete implementations that are still supported. This is not an invitation for lisp fan boys to stomp their feet, TIOBE doesn't have any (()())()(()) language in the top 20. Debate rankings all you want, but lisp type languages are extremely rarely used because people don't find them productive when given a choice.

> There isn't a philosophical difference.

I think that’s key to understanding the issue, so I guess the conversation is over.

Sorry, you're right. Let me clarify my response. "There isn't a philosophical difference addressed in the linked article"

There is clearly a pedagogical/philosophical difference, and that is usually what is used to justify using Scheme.

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.

I would say that it's lesser than macros because macros let you write a "metacircular compiler".

You can maintain performance across multiple nestings of compiled languages.

Where as if we write a metacirular interpreter in a compiled Lisp, we now have something lesser than the host language: an interpreted dialect. And then, if we write another meticircular interpreter in that dialect, we have something even slower: and interpreter interpreting the code of an interpreter which interprets code. With each level of embedding, we lose orders of magnitude of performance.

Metacircular interpreters are good for showing something cool: that you can document a possible model of how a language works using nothing but a small amount of code in that language. Someone who has learned how to use the language can then read that small amount of code understand it and acquire that model easily. Hopefully with the understanding that's not the only model. (Like for instance that lexical variables don't have to be an association list extended by consting.)

And of course academics have studied metacircular interpreters, and their theoretical properties. In that way they're also legitimate objects of interest.

Fascinating!

I've seen references to Dan Friedman's work on this in the '80s. It looks very powerful, but he's said it made his head hurt. I bet there will be fruitful research layering interpreters like this with AI code generation.

Also, Nada Amin and Tiark Rompf had something to say about this:

https://dl.acm.org/doi/10.1145/3158140

"12 CONCLUSIONS

We have shown how to collapse towers of interpreters using a stage-polymorphic multi-level λ-calculus λ↑↓. We have also shown that we can re-create a similar effect using LMS and polytypic programming via type classes. We have discussed several examples including novel reflective programs in Purple / Black. Looking beyond this paper, we believe that collapsing towers, in particular eterogeneous towers, has practical value. Here are some examples:

(1) It is often desirable to run other languages on closed platforms, e.g., in a web browser. For this purpose, Emscripten [Zakai 2011] translates LLVM code to JavaScript. Similarly, Java VMs [Vilk and Berger 2014] and even entire x86 processor emulators [Hemmer 2017] that are able to boot Linux [Bellard 2017] have been written in JavaScript. It would be great if we could run all such artifacts at full speed, e.g., a Python application executed by an x86 runtime, emulated in a JavaScript VM. Naturally, this requires not only collapsing of static calls, but also adapting to a dynamically changing environment."

(2) It can be desirable to execute code under modified semantics. Key use cases here are: (a) instrumentation/tracing for debugging, potentially with time-travel and replay facilities, (b) sand-boxing for security, (c) virtualization of lower-level resources as in environments like Docker, and (d) transactional execution with atomicity, isolation, and potential rollback.

(3) Non-standard interpretations, e.g., program analysis, verification, synthesis. We would like to reuse those artifacts if they are implemented for the base language. For example, a Racket interpreter in miniKanren [Byrd et al. 2017] has been shown to enable logic programming for a large class of Racket programs without translating them to a relational representation. Other examples are the Abstracting Abstract Machines (AAM) framework [Horn and Might 2011], which has recently been extended to abstract definitional interpreters [Darais et al . 2017]. For these indirect approaches to be effective, it is important to remove intermediate interpretive abstractions which would otherwise confuse the analysis.

For these use cases, our approach hints at a solution where we only need to manually lift the meta interpreter of the user level while the rest of the tower acts in a kind of pass-through mode, handing down staging commands to the lowest level, which needs to support stage polymorphism. Last but not least, it is important to note that the present work is based on interpreters derived from variations of the λ-calculus, and thus leaves a gap towards collapsing heterogeneous towers of truly independent languages. This gap is especially prominent in a setting where a language level does not follow the usual functional or imperative paradigm, e.g., if a logic programming language or a probabilistic programming language is part of the tower. Thus, we hope that our work spurs further activity in implementing stage polymorphic virtual machines and collapsing towers of interpreters in the wild."

https://www.codemesh.io/codemesh2017/nada-amin

Nada Amin - Collapsing Towers of Interpreters - Code Mesh 2017

https://www.youtube.com/watch?v=Ywy_eSzCLi8

Tiark Rompf - [POPL'18] Collapsing Towers of Interpreters

https://www.youtube.com/watch?v=QLyBxXqml5Y

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.

You have to trust revealed preferences, not stated preferences.

> You have to trust revealed preferences, not stated preferences.

Ah, the Pepsi Challenge! How apropos. Programming language popularity is mostly driven by marketing, after all.

It's a shame that a generation of programmers raised on high fructose corn syrup and aspartame will never know the refreshment of a homemade organic craft soda[S].

After all, if Racket[R] is the language for crafting languages[L], surely it's the SodaStream of soft drinks.

[R]: https://en.wikipedia.org/wiki/Racket_(programming_language)

[L]: https://cacm.acm.org/practice/creating-languages-in-racket/

[S]: https://www.moodymixologist.com/blog/the-ultimate-guide-to-c...

Hal 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.

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.

Online SICP: http://sarabander.github.io/sicp/

To do that with Scheme/SICP, you actually have to understand the CS principles behind it. Not as much with Python, which is likely why it became a more popular choice.

Shouldn't that be the point?

I remember when universities wouldn't teach languages higher level than C/++ because "the languages changed too quickly and the 4 year degree would be obsolete by the time the students graduate". Instead, they focused purely on the low level engineering aspects of the software meeting the hardware, with only advanced classes focusing on things like AI research (pre-LLM days) or modelling fluid dynamics on specialized hardware.

Of course, this is also why most companies worth working at didn't care if you had a CS college degree or not to build a wordpress website or a SOAP/REST API. Aside from some very basic lessons learned from experience (generally understanding computational complexity and maths) most software jobs didn't need any knowledge of assembly at all, or how to write an interpreter or a garbage collector.

I spent years knowing nothing but C and I’d say it handicapped me in many ways. (I recall insisting that it would be impossible to do anything without assignment.)

After getting my eyes opened a little bit, I read SICP and it was mind blowing. I read a little Haskell, wrote a little Clojure and a lot of Scala. And even though the day job now is Java and Python, I’m much better off for having bothered to learn it.

That's what I'm trying to say. SICP teaches you to think differently and "grok" the CS concepts. This isn't always the case with other approaches, which can be much more reliant on blind copy-and-paste and library functionality.

The point of Scheme SICP is that it will teach you these CS principles.

I fondly remember doing a course in my CS degree that was basically working through SICP as a class, taught my an ancient but very fun and enthusiastic tenured professor. When he retired I think the curriculum was updated to JavaScript (??) or as the new professor called it "scheme in drag". I'm glad to have taken the original course..

Honestly, the new professor wasn't too far off. I've often referred to "The Little Schemer" as "the best javascript book that isn't about javascript."

The official SICP site is here, including the text.

https://mitp-content-server.mit.edu/books/content/sectbyfn/b...

pdf

https://web.mit.edu/6.001/6.037/sicp.pdf

Yep, and there's a Texinfo version too. With Chicken, 'sudo chicken-install srfi-203 ; sudo chicken-install srfi-216; Emacs, Geiser and this ~/.csirc, you can run SICP exercises on really constrained environments.

~/.csirc

   (import scheme)
   (import (srfi 203))
   (import (srfi 216))

Texinfo version:

https://zv.github.io/sicp-in-texinfo

Run Emacs. Press

   Ctrl-u Ctrl-h i

and choose the sicp.info.gz file.

Then, run:

Alt-x

package-refresh-contents

Alt-x

package-install

geiser-chicken

wait.

Run Alt-x geiser, and if it ask you which Scheme interpreter to run, choose 'chicken'.

Later,

press Ctrl-x f

to choose a file, create a new one called "hello.scm".

Write in that file:

(display "Hello world").

Run Ctrl-c Ctrl-c

and then the Scheme code in that file will be evaluated. To choose the running Chicken interpreter, press

Ctrl-x b

and choose the Geiser buffer.

Run Ctrl-h t for the Emacs tutorial, it will be handy.

If you want the same tutorial in Spanish, Japanese, French...

press

Ctrl-u Ctrl-h t

and just input your language, press [TAB] to autocomplete.

Happy Hacking.

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.

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.

basic programming should be taught in high school too.

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.

Eh, being able to skip parsing allows a fairly short book to spend more time on its real focus than it otherwise would.

https://archive.is/20150709075141/http://www.wisdomandwonder...

>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.

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."

Because Worse Is Better!

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.

His top students were capable of entirely understanding Scheme within a day or so (but not capable of entirely understanding all of Python and all of PyPI). He wanted students to be even better than that. He wanted them to lead productive and resilient collaborations even when they didn't or couldn't entirely understand the small parts.

Given a day, top students can understand enough of Python to write enough code to get the point about how programs rely on abstraction and composition.

(Of course, the latter part of the course, describing the implementation of the runtime, would need considerable rethinking.)

> Engineering is still about taking small parts you understand entirely and using simple techniques to compose them into larger things you want.

Engineering fundamentally is still about that. But what people seem to do with computers nowadays mainly involves composing already-large parts that they absolutely do not understand. Often with disastrous results.

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 ¯\_(ツ)_/¯

Considering the target students of MIT CS department, I'd argue that they could simple start from an interpreter class in Python.

As in, write a Scheme interpreter in Python?

  Parens, parens, every where,
  And all the conses link;
  Parens, parens, every where,
  Nor infix op to think.

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.

Good writeup...it's two answers in one ;)

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.

It will never make sense to me to teach one language (Scheme) to learn one thing (how to program) when you can use a different language (Python) to teach two things (how to program, actual specific syntax you’ll use forever)

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 feel some people are way too passionate on the topic of which languages should be taught first. It doesn't really matter.

Did anyone notice this announcement was from 16 years ago? I very much doubt this is the current state of the MIT coursework.

I hated learning Scheme on their free open courseware. Yet I loved that it was free :)

Decline.

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.

Epstein preferred python and persuaded MIT to make the switch

Reply on news.ycombinator.com