Chas Emerick

Reading a short account of the rationale behind the change, described by Sussman himself, paints a very different picture: http://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/ .

It's not that programming now "largely consists of debugging and customizing already existing code, often via frameworks". For one thing, it's only the narrow, web-constrained definition of "framework" that even vaguely works that way. Second, I'd argue that, unless the code which programmers debug has been written somewhere until the late 1990s, new code gets written often enough that programming largely consists of writing new code instead of debugging old one. That there are programmers hopelessly churning on the umpteenth bug because someone at the end of the Internet decided to change the format of their JSON objects and the mapping of their HTTP request handlers (pretentiously calling that "an API") is not a testament to how programming has evolved, it's merely a proof that not every change counts as evolution.

Instead, the choice of Python over Scheme -- which has been received with mixed feelings by almost every programmer able to write a Quicksort function without googling for compiler errors -- seems to have been driven by related, but vastly different reasons, such as:

* There are vast amounts of interactions spread over multiple languages, machines and platforms. Independently reasoning about objects, while essential to programming,…

> I think it's worth pointing out why the author's of SICP themselves acknowledge why it was phased out.

Gerald Sussman made some remarks about this during an unrelated roundtable discussion at the 2009 International Lisp Conference:

https://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/

Note that Sussman did not actually state why the committee decided to change the curriculum. The remarks about studying software empirically were his opinion. I was in the audience, and while Sussman seemed sincere in his remarks, I still have a hard time believing he was serious. How can anyone state, without irony or sarcasm, that we should just give up, and start treating software programs, where all the "laws" are not only known, but made up, by us, as if they were natural systems, where our only way to understand them was to start "poking" (I may be wrong, but from what I remember this was the actual word Sussman used) at it and observing the results?

If you give up before you have even started on modularity, composition, etc., and start treating every program as if it was a million line COBOL hairball, the hairball part is just going to be a self-fulfilling prophecy.

My takeaway from Sussman's remarks was the opposite of his message - the ideas about applying mathematical principles to software design in SICP have become even more relevant as a way to prevent software hairballs.

I make good money doing the "poking," but if you…

I will give my answer, noting that not everyone will agree with me :-).

The vast majority of software developers do not put up with Lisp syntax. The vast majority of software developers use a different programming language with a much better syntax, and never consider using Lisp for anything serious. For example, for most developers, a programming language is a laughable nonstarter if it cannot use infix notation for basic arithmetic, as that is the standard notation for mathematics worldwide and is taught to everyone.

As evidence, look at TIOBE: https://www.tiobe.com/tiobe-index/ ... you'll see "Lisp" is #26, lower than Classic Visual Basic, Kotlin, Ada, and SAS. Scheme and Clojure aren't even in the top 50, so adding them wouldn't change much. Lisps will never break the top 10 with their current syntax.

There is a reason for Lisp's syntax: it's homoiconic, enabling powerful macros. Lisp macros are incredibly powerful, because you can manipulate programs as data. Other macro systems generally don't hold a candle to Lisp's. The vast majority of "simple syntactic sugar" systems for Lisp lose homoiconicity, ruining Lisps's macros. This was even the problem for the M-expressions created by Lisp's original developer. Most of those syntactic improvements also tend to NOT be backwards-compatible.

There is a solution. I developed curly-infix expressions, SRFI-105 https://srfi.schemers.org/srfi-105/ Curly infix enables infix notation WITHOUT losing homoiconicity or requiring a…

I think Christophe's is the talk, and Yegge seriously misunderstood it, if he even bothered to watch it. Christophe's point was that basing the underpinnings of a DSL on macros was frequently a mistake, vs a data + functions approach that "leads to greater dynamicity". It is inarguable that macros are less flexible than functions (e.g. they can't be applied) and less composable. Christophe's argument wasn't against macros, but that they should be the last layer of sugar, not the core mechanism of a DSL. This approach has been advocated and practiced by Lispers forever. Ditto the advice to not use a macro when a function will do.

And for Yegge to imply that more serious Clojure devs like Christophe are macro averse because they are afraid they might not understand someone else's macro code shows his complete lack of familiarity with Christophe's macro skills and other work of the community.

Taking potshots at things you don't understand and people you don't know (while leaving out the link so others could verify) smells like a FOX-news rhetorical approach to me. Ditto political labeling (though in the programming community the negative tag is "conservative", whilst in politics it is "liberal"). Tag the thing you don't like with the negative label, then rationalize, and spew misinformation. "Clojure's community came pre-populated with highly conservative programmers from the pure-functional world: basically Haskell/ML types": surveys[0][1] say... nope.

He even ignores the…

I've heard that actually students who had never programmed before did better with SICP than students that had. You have to un-learn a lot of habits from imperative languages when you start working with Scheme. Total novices could take the material as it was presented, but people who had programmed before often tried to shoehorn it into the C/Java/PHP paradigm they'd already experienced and ended up fighting the language.

The same effect worked in reverse as they graduated MIT or worked on projects in more mainstream languages, though. Students would have to unlearn some of the elegant recursive formulations and strong abstraction abilities of Scheme and deal with languages that actually have strong industry adoption. That was a major factor [1] in the replacement of SICP with Python in MIT's intro programming class. Python has abundant library support that more closely mimicks what the programmer will have available and what challenges she'll face in the real world.

[1] https://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/

A few years when MIT switched from SICP/Scheme to Python, Sussman had this to say:

"I asked him whether he thought that the shift in the nature of a typical programmer’s world minimizes the relevancy of the themes and principles embodied in scheme. His response was an emphatic ‘no’; in the general case, those core ideas and principles that scheme and SICP have helped to spread for so many years are just as important as they ever were"

From: https://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/

If anything, I would think Sussman is more practical, and understands what the world needs/expects(now).

Literally any programmer who hasn't read SICP before will benefit from it. I think the principles still apply.