[bertruss]

I take the long term view. In the 40's and 50's, computer scientists were lucky if they could flip switches to enter binary data into a computer - no tapes or punch cards. When they got tapes and punch cards in the 60's, they could boot the system from a tape and run a program by stack and loader deck on the front of the job. Then disk drives came along and eproms and those would boot the system and NOBODY CARED ANYMORE about flipping switches or running paper tapes. Well, actually, somebody cared - but it wasn't the young computer engineers. Then microchips reduced all the complexity into invisible little chips. What happened to flipping switches to enter binary boot code into the system? We forgot how to do it - and guess what, there are more computers running more programs now than ever. My students write more programs in their first week than I wrote in an entire semester of my first comp sci course. Nobody is trying to record programs and cassette tapes like we did with the Radio Shack trash-80s in the late 70's. I still have a box of floppy diskettes on my desk - I pick one up whenever I need a warm fuzzy feeling of security. But we don't have any floppy drives in the lab.

We've come a long way, and a lot of technologies have become obsolete and basically meaningless. They were interesting then, and they are still interesting from an historical standpoint. But I don't think we need to start off new computer science students at the bottom of the ladder, flipping switches. Fact is, the students simply won't accept it. Am I pandering to their laziness when I teach them how to code GUI interfaces in Java (we do code them - we don't use a GUI design tool)? Am I racing into an uncertain future when I give them modern tools and modern problems to solve, instead of coding a quick-sort in assembly language?

I don't believe the future is that uncertain. And I don't believe that low-level, "close to the metal" programming is going to be performed by the software "engineers" that are apparently disappearing. Indeed, software engineers should probably learn more about design and system interface issues than electronic engineering and hardware drivers. As systems get larger and connect more and more components together, we aren't even managing to write software that takes advantage of multi-core CPU technology - we don't have useful tools for parallel processing. I talked to a software engineer at the European Space Agency and asked him how many people are still programming in assembly/machine language for the equipment on their space probes. He said "virtually none - the low level stuff is all done - most of our programmers are writing code in Java". I was pretty surprised.

My take on Java is that it isn't "too easy", but rather too DIFFICULT for beginners. If Java and C++ and "Visual whatever" are the languages being used in production environments, then they probably are not appropriate for "beginners". I'm not a big fan of Scheme - maybe Logo or Alice or some other "eye-candy" is a good starting point. Java can come later. And if we actually still need C++ progammers 10 years from now, I imagine that experienced programmers will figure out how to write code in that language. If it were true that the "first language" has lasting effects, we better take all the PCs away from the school kids before they "wreck their brains" using easy tools.

It's not the specific language that matters anyway, but the general concepts. Booting up is a similar concept whether it involve flipping switches, using a floppy diskette, or relying on ROM and hard-disks. Arrays might look different in Python than in Visual Basic, but the basic concept is the same. If you don't understand OOP, you won't be able to program in an OOP environment no matter how helpful the IDE is.

Concentrate on the general concepts and use the best tools available. The tools are going to disappear anyway, so it only matters that they are good at the time. As one researcher said, over half of the "knowledge" that Computer Science students learn during college is obsolete before they graduate. If that's true, then it's not the right knowledge. If they are learning the names of Java class libraries and that counts as knowledge we really have missed the point. But that doesn't mean we should throw out Java - rather, give assignments that address the real issues (Big O and NP completeness are still issues). Just DON'T GIVE assignments where the solution can be "cobbled together" from existing classes.