The logical culmination is modern ML, where no engineering is involved. "If the thing fails on some case and kills somebody, train it more." This is voodoo, not engineering.

Given Sussman's aversion to mysterious black-box AI, that's an interesting observation. The curriculum change brings everyone one step closer to not really understanding how things work.

Of course, it's often pointed out, "Well, if you write in Scheme (or C or Java or whatever) then you're not writing in assembly language, much less machine language, so you already don't understand everything." There's certainly truth there, but, to me, going from, expertise writing code in a high-level programming language to, gluing together libraries that you kinda-sorta understand, feels like a bigger leap in what you do or do not understand than going from assembly language to Python.

I suppose it depends on what issues we should consider to be introductory. Maybe the older theoretical approach was more fundamental then than it is now. Like, maybe that was effectively more practical given the old hardware performance constraints and likely having more control of the entire program stack.

It's interesting that Sussman kind of lumps together "uncertain software libraries" into the same category as machine control robustness (e.g. hysteresis). I never thought of it that way but I guess in practice it's all just "stuff", those libraries are just another piece of your program's environment like any other.

Maybe MIT approaches post 2000 engineering with a solid foundation of analysis that creates both a beautiful creation process and reliable beautiful software artefacts. But what I observe is a never ending stream of partial doc reading, partially out of date, with random attempts until it looks it won't fail it left running for a few minutes.

Ability to deal / reflect with unknowns for engineering is of great value, but so far I've never seen that in office.