I do strongly think that people, when they start throwing computers at something, they think that it's a whole new ballgame, so why should they study the past. I think that is a terrible mistake.
-Donald Knuth

Those who do not remember the past are condemned to repeat it.
-Santayana

One thing that's always struck me throughout my career as a professional in computing has been how little regard or study we give to the history of our profession.

I suppose this situation has been engendered to an extent by the rapid growth in the technologies we work with. It hardly seems possible sometimes that lessons learned long ago (when FORTRAN pterodactyls roamed the Earth, or when PL/I T. Rex feasted upon COBOL flesh) could have any relevance in a Web services world or help us deal with adapting object orientation to a playing field where databases are by and large relational.

Of course, being a certified old-school fogie myself, I'm certainly guilty of holding forth on how romantic and primitive things were back in the day ("walking 10 miles to school in the snow, uphill both ways, with a Teletype strapped to my back and we liked it!"); that sort of nostalgia doesn't sell well to the current population of the community. That said, I really do believe that we don't spend as much time as other engineering disciplines do on understanding how things used to be done and, more important, why.

Knowing this will help us understand why things are as they are now, and how they got to be that way, and might well shed some light on the way forward.

By way of an illustration, think for a moment about the perennial debate between adherents of C/C++ language technology and advocates of Java (or other virtual machine–based languages). One often heard plaint from the C people is that hand-crafted C code is inherently more performant than anything possible through "an interpreter," and therefore whatever benefits the newer approach might have aren't worth the cost of not being able to wring every last cycle out of the machine, runtime optimization possibilities notwithstanding.

A "new" debate? Not exactly. Consider this reply:

What about the classical objections to such a tool? There are three: It doesn't let me do what I want. The...code is too big. The...code is too slow.

As to function, I believe the objection is no longer valid. All testimony indicates that one can do what he needs to do, but that it takes work to find out how, and one may occasionally need unlovely artifices. As to space, the new...compilers are beginning to be very satisfactory, and this improvement will continue. As to speed, [optimizers] now produce some code that is faster than most programmer's handwritten code...

Perhaps you can see I've edited the above just a little to avoid tipping my hand. As familiar as it may sound to today's ear, this isn't a recent apologia for Java technology. The author was the venerable Fred Brooks, and he was talking about the debate over using assembler code versus PL/I in the Operating System/360, developed for IBM mainframes, consuming (by his estimate) 5,000 man-years of effort from 1963–1966.

Now that's old school, right? Brooks was writing in The Mythical Man Month of lessons learned in a project completed two years before I wrote my first computer program. MMM was written in 1974, around the time I entered the industry on a paid basis. This is fully four years before the 1978 copyright date of my copy of Kernighan and Ritchie's The C Programming Language, so we can say that the "don't use {higher_level_language_X} because it isn't performant" debate is not only older than Java, it's actually older than C. Originals of both books live in a spot of honor on my bookshelf, next to their 20th anniversary editions, themselves now getting a bit long in the tooth.

That particular debate is now fully thirty-some years old, would you say? Not quite...

Here's another quote from a different source, and I won't monkey with this one at all, since you know something of what I'm up to now: The first programming system to operate in the sense of a modern compiler was developed by J. H. Laning and N. Zierler for the Whirlwind computer at the Massachusetts Institute of Technology in the early 1950s...it was, in John Backus' words "an elegant concept elegantly realized"...he also remarked that it was all but ignored because it threatened what he called the "priesthood" of programmers, who took perverse pride in their ability to work in machine code using techniques and tricks few others could fathom, an attitude that would persist well into the era of personal computers.

Donald Knuth...saw another reason in the allegation that the Laning and Zierler system was slower than a factor of ten than other coding systems for Whirlwind....Closing that gap between automatic compilers and hand coding would be necessary to win acceptance for compiler systems and break the priesthood of the programmers.
-A History of Modern Computing by Paul Ceruzzi

Now this is recognizably the same debate, taking place nearly two decades before Brooks' project.

The writing has a consciously historical bent, and it offers some insight into reasons why the newer technology was rejected by the establishment...reasons that perhaps didn't have as much to do with the technology, but more to do with "programming as a human activity" – a delicious turn of phrase we owe to Jerry Weinberg's classic The Psychology of Computer Programming, a work of the same era as Brooks' book. More understanding of the "paradigm-shift" pattern at work here (and please pardon my use of the word "paradigm," oft-abused by New Age management theorists of the 1990s) is available in another book from that shelf, Thomas Kuhn's The Structure of Scientific Revolutions.

Perhaps if today's developers had a higher awareness of this kind of historical background, we'd spend less time on old debates and more time thinking about newer issues. Goodness knows we have enough of those to deal with.