Criticizing First Language Choice in CS Curricula

Posted by Thomas Gideon on 10 January 2008

The article Slashdot references is from a journal on software engineering for the defense industry. Provably correct software is a big deal for hackers in that trade and probably colors the editorial a bit.

It is important to not that this is not a lambasting as Java in education, but its selection as a first language. I think you could easily stub in a whole slew over other, simple languages and the commentary would make as much sense. However, I cannot disagree with their view that educators have shifted to Java as a first language to cater to perceived industry demand.

Outside of the author's industry, I would have to downgrade their concerns over mathematics. Maybe for pure research, like algorithmic complexity, or systems engineering math is still critical but for general programming, not as much. I would lump their comments on understanding discrete, floating point math alongside Java fostering an ignorance of machine architecture. I know my own entry into programming via Java and similar languages delayed my full understanding of low level machine architecture, organization and operation. I cannot say it has hurt my career overly much but I doe recognize that if someone ignorant of these topics was working on real time, embedded software, that would be a huge risk.

More generally, I agree with their issue with any curriculum that takes more of a cookbook approach. I think the implication that CS curricula need to train engineers how to problem solve more generally with good discipline, regardless of particular technology or language, is one I can readily endorse.

However, the economic reality is that much paid development is simply application development that really is little more than plumbing. Systems engineering and other more demanding disciplines have been in decline in the market for some time. It is unrealistic to train every CS graduate for the minority need in the marketplace.

I don't think application development would be hurt, really, by better low level understand and skills. I just don't think the time or cost required is appropriate for situations of scale. That is to say the majority of work for which the software programming market is currently paying. Better to ask how to ensure at least a viable minority of systems engineers are produced each year to balance the majority and ensure there are always some engineers of all required stripes. Honestly, systems engineering will never go away but neither do I think its proportion in the paid workplace will increase in relation to applications development.