Software developers spend most of our time re-inventing the wheel. Everyone who works with computer types has run into the “not invented here” and “I can do it better” mentalities, or fallen victim to them themselves. But I think this goes beyond that. Software developers seem, to me, to be wilfully ignorant of past work. Not only do we not know about it, we don’t want to know about it!
Mark Dominus demonstrates one example of this while examining the whole “Design Patterns” mess. The “Design Pattern” movement seems to be unconsciously based on this ignorance of history, through an assumption that modern programming languages are the be-all and end-all of programming languages, and always have been. As Dominus puts it:
If these problems recurred in every language, we might conclude that they were endemic to programming itself. We might not, but it’s hard to say, since if there are any such problems, they have not yet been brought to my attention. Every pattern discovered so far seems to be specific to only a small subset of the world’s languages.
Some awareness of the history of programming languages might produce a slightly greater awareness of the trends Dominus identifies in the history of programming language development. It might help us avoid re-treading the same ground over and over while claiming that we’re exploring new territory. Perhaps we could even focus our attentions on the areas of language development that actually need work?
Another excellent example is this recent article on Internet software patents by Philip Greenspun, who correctly identifies that most modern software “innovation” is rehashing the work of early pioneers. We’re just scaling that work in obvious ways to take advantage of increased system capacity, or making half-cooked implementations of ideas that these pioneers devised in a much more robust form but were unable to follow through with.
Looking back on my computer science degrees, I’m honestly confused about why there wasn’t more history taught. We got a lot of algorithms, mathematics, and mainstream languages (C, C++, Java) thrown at us, but very little history of or context for the things we were learning. Except for Dr. Grundke’s second-year assembly language course and Dr. Cox’s third-year programming languages course, it wasn’t until fourth year courses or graduate work that historical matters were mentioned at all. And even then, no consideration was given to the implications of the history or its influence. It was written off as obsolete, interesting but largely irrelevant. Even in graduate courses, my experience shows a near-exclusive focus on recent history.
Yet Engelbart’s NLS did things that modern computer systems still can’t manage. Modern programming language and environment development seems to put a lot of sweat into developing poor copies of Smalltalk and LISP. Years of time are put into recreating things that our Internet protocols can already do, because the existing programs that implement these protocols don’t. I’m not saying these older solutions didn’t have their flaws, or that there haven’t been original new developments. But the history of these older technologies at least merits study, so we can focus on improving the things they did wrong and take advantage of the things they did right. Unfortunately, many of the students graduating from computer science programs (possibly the vast majority, including many graduate students!) are as completely unaware of this rich history as they are of modern developments.
This is particularly strange to me, because one of the big motivators for my interest in computers was Steven Levy’s Hackers. Levy’s examination of the early days of the computer movement was inspiring and educational. While non-technical, it provided some good examples of what does work (openness) and what doesn’t work (secrecy), which almost certainly shaped my interest in the Free Software movement. Towards the end of the book, he also inadvertently demonstrates the importance of historical awareness by following people who were sure that history was irrelevant. This lack of awareness doomed them to repeat their predecessors’ mistakes, eventually leading to the collapse of their movements, companies, and technology.
I also have to wonder how much influence the proprietary software movement’s had on this mentality. When your ideal model of software development is behind closed doors, you have to pretend that there’s no need for awareness of other technologies, much less awareness of how they work. If you recognize that reading, working with, and building on notable programs and technology written by others is valuable, the claim that software innovation requires absolute secrecy starts to look a little shaky.
TLDR: what I want to see is a required course - possibly even a full-year course! - on the history of computing. A proper history course, one that critically examines the causes and effects of events, their influence, and forces the students to become aware of these historical pioneers and the technology they developed. Teach them what it did and what it didn’t do. Heck, if it’s feasible, make them use it a little.
Just a note:
Since the required courses are paid from grants, there is typically no chance to include a new one to the syllabus. Not required course must be enough.
I’m not so sure about that. I think it may depend on how the university in question’s organized. The university I graduated from has changed its syllabus several times since I started there. And not only has the selection of required courses changed, but the number of required courses has changed too. I’m also not particularly enamoured with the structure of the first couple years of most CS programs, so I’ve got no problems with advocating wide-ranging changes to them.
I’d be interested in knowing just how fixed the syllabus is at many universities. If it is, as you say, determined entirely by grants rather than educational concerns, that’s a very sad state of affairs.