I find the first part of the explanation rather puzzling. According to the post, the old way of writing the software was like so:
In 1980, computer engineering was based on starting with clearly-defined things (primitives or small programs) and using them to build larger things that ended up being clearly-defined. Composition of these fragments was the name of the game.
And the new way of writing software is described as:
However, nowadays, a real engineer is given a big software library, with a 300-page manual that’s full of errors. He’s also given a robot, whose exact behavior is extremely hard to characterize (what happens when a wheel slips?). The engineer must learn to perform scientific experiments to find out how the software and hardware actually work, at least enough to accomplish the job at hand.
Huh? Now perhaps I'm not a real engineer, so my experience doesn't apply. But, 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?
And yes, nowadays a programmer does typically start with a large API. But I'd hardly say that they are "full of errors." Sure, there may be some issues with the Google Finance API or JDK, but I'd hardly say that the main issue a programmer has is these errors. And besides, thanks to Forum Effect - any issue you have has most likely already been discussed on a forum somewhere, and is just a Google search away.
And yes, it's critical that a programmer learns to run little experiments - but that process is essentially debugging and has certainly been required since the 1980's, if not since the days of ENIAC.
The explanation continues to be a little whacky to me:
The new approach also has the big advantage that it combines computer science with electrical engineering, whereas the old one taught them as entirely separate disciplines. This way, students see how they interrelate.
Again, huh? How is computer science interrelated with electrical engineering? Computer science, to me, is the study of problem solving - not electricity whizzing through CPUs and RAM.
And finally we arrive at the point in the argument that I can appreciate:
There is extensive lab work, making robots and mobile applications.
Aha! By mixing EE and CS, you've put yourself in a position where you can program some hardware - the result is that you're doing something fun, like programming a robot. Instead of doing boring math, you're doing fun robotics.
The Ideal Education
If you ask me (and certainly, nobody in their right mind would), your ideal intro CS eduction should try to balance two competing goals:
- Make programming fun/relevant so folks will want to put up with the pain of learning how to do it well.
- Teach as many good habits, and as few bad habits in the process
MIT, it seems to me, has solved at least part of the above equation. They're doing fun lab work instead of traditional (read: boring) programming. I'm not sure why they think they need to justify the fun by associating it with EE, when you could easily mix programming with finance, music, biology or any other discipline. But hey, robots are cool. Along with the fun, I suppose you can learn good style with Python, so perhaps they have the second point nailed too.
They accomplish goal #1 above by targeting the Android phone platform. Students can write games and apps that make use of the phone's GPS, accelerometer and networking capability among other items. Definitely no boring code here.
They accomplish goal #2 by using a modified version of the Scheme language known as the Beginning Student Language. Because of the rules of the language, students end up with small, easily testable procedures. This starts students down the path of learning important lessons about modularity and debugging, and avoids dependence on global variables or other habits to be unlearned later.
The Moby Scheme project is still in its infancy - but I think the team is really on to something.
So, you heard it here first: MIT went from Scheme to Python, and in a couple of years, will be back to Scheme.