Great comments
Really enjoying this stuff.
A few things I would like to add to the mix, in no particular order:
1) IMHO, one of the biggest problems is the skill sets of the 'new generation' of programmers. I had a graduate who apparently was a Java guru. Yet he had no concept of ASCII. He did not understand *how* toLower (or LCase in VB) *actually* worked. To him, it was just 'magic black box' stuff.
2) Given the above, if we gave that graduate, say, a 40 core Intellasys processor (which are available now, off the shelf, yes, *FORTY* cores), what would he do with it?
3) All of the above does not mean that this graduate is thick/stupid/whatever. Actually, he was really bright, and has gone on to do well. However, the standard of his degree course at university was appalling. Until we can get back to 'brass tacks' in the educational side of things, we are not going to produce people with the *knowledge* (note: not talent; you are born with talent) to take the latest multi-core processors and do something truly radical, and ground breaking with them.
4) One day, I got two graduates together. I put the following to them:
"We need to build a computer system that can control a radio telescope. A big huge fucking radio telescope. Not only will it control the movement of the dish in real time in order to track moving objects in the sky, it must also gather the data received from the telescope and store it so that it can be reviewed in real time, online, by multiple users at the same time. Furthermore, the data should be stored historically and available for instant recall so that comparisons can be made with older data. All this, while ensuring that the telescope is moved efficiently, without burning out the motors in the drive gear. What do you suggest?"
They came up with credible solutions, none of which were wrong particularly, and were a reflection on modern programming/system analysis thought trends...
"Well, we'll use a few computers... One for an SQL database, one for tracking the telescope, and one for viewing data."
"Ok, great. But that's an awful lot of processing power. How will they communicate with each other?"
"Using XML over a LAN."
"Yes that will work. But if you use XML, you will need an XML parser, and code to package your data into XML packets - some sort of object model..."
"Yes, we will abstract each item of data into objects, these can remoted over the LAN using SOAP."
"Ok, its sounding pretty cool. XML is really only useful though when you need to share your data with third parties, where it needs to travel through firewalls, and be parsable by another machine that may not necessarily be running the same platform as you. We're talking about a system that is self contained, connected via a switch. Couldn't we just use sockets and our own protocol? Wouldn't that be much more efficient?"
"Well yeah, but, that would be difficult..."
Then I leave them goggle eyed when I say, "actually guys, I'm pulling your chain. This problem has already been solved. In 1971. By Chuck Moore. He did the whole thing on one PDP-11 with a single disk drive and 32K of RAM."
Sometimes, I really do think we've gone backwards.
Mines the one with the "Threaded Interpretive Languages" (1981) book in it. Sometimes we should go back and read the old stuff, lest it not be forgotten. It might teach us something.
Mark