I don't have an opinion about the Scheme -> Python switch, but I didn't find this a very compelling objection.
The author seems to assume that a CS degree is meant to teach you to write software. (E.g., "how exactly do you write software if you don't start with small working primitives (like unit tested classes, PLT scheme modules, or a PHP library script)? Isn't taking a complex problem and breaking it down into testable/reliable chunks a fundamental principal of writing software?") But who said anything about writing software? Certainly many CS grads do go on to write a fair amount of it, but it's hardly the only goal of the curriculum, especially at a place like MIT, where a CS grad is as likely to go on to a career in research as in programming.
The priorities here seem frankly bizarre; the author derides learning about "electricity whizzing through CPUs", but the principles governing how CPUs work are way more core to computer science than is unit testing, which is more of an industry best-practice than a deep principle.
Looking at it another way, a full education in CS is going to have to cover everything from processor hardware to programming techniques to theoretical foundations. Intro courses at most schools have tended to focus almost exclusively on programming. The old SICP-based intro course at MIT blended programming with a taste of theory, and the new intro course sounds like it will switch to blending programming with a taste of hardware and a crash course in real-world problems like faulty and undocumented libraries. I wouldn't say that's obviously a good move, but it's not obviously wrong, and it doesn't seem any less true to the soul of computer science.
Well me personally, I love SICP, I think it's one of the most important books to read as a developer.
However, I don't think its importance can really be appreciated by a neophyte programmer. The elegant modular approach to programming that is introduced in SICP seems like too much work until you have been programming for a while using the large, buggy, mostly undocumented APIs that the working developer has to deal with. (the blog post above seems to think that these don't exist, and all I have to say is that he has either been very lucky or doesn't do a lot of coding)
I always felt a first programming course should actually teach assembly first, then C, then an OOP language like Python or Java. If you are unaware of how the higher-level languages actually get mapped into the world of pointers and registers, it's really hard to understand performance issues, and how the various higher-level languages evolved in the way that they did.
All things considered, I think most people would agree Python is easier to pick up than Scheme, especially for someone who has never programmed before. As long as they eventually do teach a purely functional language at some point and introduce the concepts of functional programming, I think this is a great change.
Surely making a robot move around is more fun than calculating the Newton-Rhasphon method? :)
Python is easier to pick up than Scheme, except for someone who has never programmed before. Scheme has the simpler syntax and semantics, but Python is more likely to resemble programming they've already done.
And yes, making a robot move around is fun. SICP wasn't designed for fun. During the late '80s and early '90s it was a weeding-out course when too many people wanted to major in EECS. I thought it was fun, but a lot of people didn't.
Testable and reliable chunks are totally cool, but they are increasingly unrealistic and "passé". Modern systems use lots of unreliable parts which are not well defined (eg Google's server farms), and before long (especially at MIT) there will be quantum computers whose behavior will be impossible to exactly quantify or predict. Teaching students how to get real work done in these uncertain environments is definitely preparing them for real computing systems of the future.
I wonder how much of it can still be called science when all it does is with incomplete unreliable and unpredictable stuff. We can rename it "Computer Magic" or "Paracomputology"
The author seems to assume that a CS degree is meant to teach you to write software. (E.g., "how exactly do you write software if you don't start with small working primitives (like unit tested classes, PLT scheme modules, or a PHP library script)? Isn't taking a complex problem and breaking it down into testable/reliable chunks a fundamental principal of writing software?") But who said anything about writing software? Certainly many CS grads do go on to write a fair amount of it, but it's hardly the only goal of the curriculum, especially at a place like MIT, where a CS grad is as likely to go on to a career in research as in programming.
The priorities here seem frankly bizarre; the author derides learning about "electricity whizzing through CPUs", but the principles governing how CPUs work are way more core to computer science than is unit testing, which is more of an industry best-practice than a deep principle.
Looking at it another way, a full education in CS is going to have to cover everything from processor hardware to programming techniques to theoretical foundations. Intro courses at most schools have tended to focus almost exclusively on programming. The old SICP-based intro course at MIT blended programming with a taste of theory, and the new intro course sounds like it will switch to blending programming with a taste of hardware and a crash course in real-world problems like faulty and undocumented libraries. I wouldn't say that's obviously a good move, but it's not obviously wrong, and it doesn't seem any less true to the soul of computer science.