2026.10.30
In my years in computing I’ve noticed a fallacy akin to one described by Herbert Butterfield in The Whig Interpretation of History:
It is part and parcel of the Whig interpretation of history that it studies the past with reference to the present; and though there may be a sense in which this is unobjectionable if its implications are carefully considered, and there may be a sense in which it is inescapable, it has often been an obstruction to historical understanding because it has been taken to mean the study of the past with direct and perpetual reference to the present. Through this system of immediate reference to the present day, historical personages can easily and irresistibly be classed into the men who furthered progress and the men who tried to hinder it; so that a handy rule of thumb exists by which the historian can select and reject, and can make his points of emphasis. (page 11) . . . Our assumptions do not matter if we are conscious that they are assumptions, but the most fallacious thing in the world is to organize our historical knowledge upon an assumption without realizing what we are doing, and then to make inferences from that organization and claim that these are the voice of history. It is at this point that we tend to fall into what I have nicknamed the Whig fallacy. (pp. 23-4).
In other words, Butterfield warned historians that they risked compromising their work by applying contemporary value judgments against historical figures or events, and assuming that factors we perceive as advantageous to our current condition or favorable to development in any particular field must necessarily be deemed as inevitable and progressive. The Whig fallacy thrives on the assumption that a given concept or artifact embraced by a segment of contemporary society is the logical and only legitimate result. In accepting it, anything that deviates from modernity must be viewed as wrong and anything before it as immature or out of touch and supposedly forgotten by virtue. I see a similar tendency in how older computing books, papers, and ideas are regarded. A text describing an obsolete language, a defunct operating system, or primitive hardware is easily dismissed as having little to offer a contemporary reader under the assumption that technology always supersedes its precursors. But this is just another application of the Whig fallacy: it conflates the passing of a technology with the passing of the ideas associated with it.
There are many reasons not to dismiss old ideas outright, but one is of particular interest to me. Computing has a history of ideas constrained by the capabilities available to their time of conception: memory was expensive, processors were slow, storage was limited, and necessary hardware sometimes did not exist. What was reasonable in conception might have been impossible or prohibitively expensive to pursue at the time. Yet what was once impractical may now be achievable, and what was once speculative may now be realizable. Alan Kay once described Xerox PARC’s approach as building systems so far ahead of the curve that the team could discover what to do with them by the time the rest of the world caught up. How many such systems are waiting for their time to come, and is their time now? There are many ideas that were neither disproved nor rendered impractical, but were only displaced. The history of computing is not a linear succession of improvements where every new development absorbs the worthwhile contributions of its predecessors. The reality is much messier collection of competing ideas, abandoned approaches, misunderstood problems, and alternative ways of understanding. The systems that became dominant represent only some of the possibilities that people explored rather than the limits of possibility itself.
My most assiduous reader will not be surprised that I find considerable value in studying “obsolete” systems. That being true, I don’t expect that every technique I encounter will have an immediate, or even eventual practical application, nor should they always be.1 What often interests me is the intellectual activity that they preserve: the ways people approached problems, organized their thinking, conceived of systems, explored the possibilities of computation, etc. I increasingly regard these works as lenses for examining systems design. The hope is that I might find an approach worth borrowing or a concept that changes how I understand a problem, or simply acquire another lens to look at a problem that I might encounter years later. Sometimes, different systems and ideas reveal different aspects of a problem, and the more perspectives one has encountered, the greater the range of possibilities available when approaching something new. Isn’t the value of a lens that it makes something visible that might have gone unnoticed?
Look, I hope it’s clear that I’m not implying that older systems are inherently superior and that every forgotten idea is worthy of resurrection. Some approaches really have been superseded or were not very good, but I would rather make those judgments after engaging with the ideas. I won’t lie, I have an intellectual pleasure in encountering the concerns and ambitions of people who were exploring computing under very different circumstances. Studying these works gives me a sense of participating in a much longer conversation about the nature and possibilities of computing, but I don’t expect everyone to enjoy it in the same way. But as a systems designer, I strongly that that there is value in keeping those earlier perspectives within reach. Not because they necessarily provide answers, but because they enlarge one’s possibility space.
There are many older works that have enriched my systems design tool-chest, but a few stand out as particularly useful lenses:
John McCarthy’s paper “Programs with Common Sense” (1958) is a proposal for an “advice taker” that is a program that reasons from declarative knowledge. Sound familiar? Indeed, this is a process that modern Agentic Software Systems2 make deceptively straightforward. This paper, while describing a system that, AFAIK, has never been implemented, has suddenly become a meta-commentary on modern software development. The ability to produce an answer is not the same as having common sense. Reasoning from incorrect assumptions can produce convincing but incorrect results. This has always been a problem in systems design and development, even in the before-times. Finally, a premise that McCarthy works with in the paper is that abstract principles are harder than familiar solutions.
William Kent’s Data and Reality (second edition) and Dean Allemang’s Semantic Web for the Working Ontologist are wonderful examples of the conceptual treatment of data, representation, naming, relationships, categories, models, etc.
Ben Moseley and Peter Marks’ “Out of the Tar Pit” (2006) is not very old, but it shows that an idea can become part of the intellectual past surprisingly quickly, even while its treatment of complexity, state, and systems design remain as relevant as ever.
Peter Kogge’s The Architecture of Symbolic Computers (1991) is good example of an alternative computing trajectory that focuses on non-von Neumann architectures for functional and logic-language computing. The book also deals heavily in the how programming languages and machine architectures might relate.
Common Lisp may seem unfashionable, commercially marginal, and mostly absent from the contemporary mainstream landscape, but its ideas are nowhere near intellectually exhausted and seemingly forever reimplemented poorly. Also, a study of its design process is infinitely fascinating in how robust systems of extreme complexity are created in the face of fractal trade-offs and nearly insurmountable conflicts of interest.
Ultimately, I think a historical perspective is increasingly valuable. Designing a system involves considerably more than producing an artifact as there are intellectual activities preceding and accompanying its construction: understanding the problem, deciding how to represent it, identifying its constituent parts, establishing relationships between them, and making judgments around alternatives. If we regard systems creation primarily as the production of artifacts we risk losing sight of much of what makes the activity intellectually interesting in the first place. This concern has taken on an additional dimension as the production of software artifacts becomes increasingly automated, but even still the larger questions of system design still depend more than ever on human judgment, taste, discernment, and experience. So think of studying and exploring “obsolete” systems as a way of maintaining and expanding an intellectual tool-chest. Every unfamiliar approach, every alternative conceptual model, and every encounter with a different way of organizing a system adds to the resources available when approaching a new problem. An ignorance of what came before makes us more dependent on contemporary approaches, particularly those that happen to be most visible and, increasingly, most heavily represented in the training data of the automation to which we delegate.
:F