Why the fascination with retrocomputing?
It's a grey, drizzly Saturday in September, and I'm wandering around a large exhibition hall full of men -- and it's all men -- in Cambridge, looking at odd bits of electronic equipment. There are various display stands, some with functioning computer-like artefacts, and some with components and parts. Later, a middle-aged gentleman is going to get up on the little stage and demonstrate his lovingly-restored Heathkit H8. There's a mood of anticipation simmering among the two hundred-or-so visitors.
No, really, there is.
I'm not sure whether to be surprised or unnerved that I'm looking at almost exactly the same kind of equipment, displayed by exactly the same kinds of people, that I saw when I used to go with my teenaged friends to the Microcomputer Show in Kensington Olympia back in the 1970s. Many of the items on display are in such good condition that they could have been lost in a time warp in South London for the last forty years.
This, you see, is a retrocomputing fair. People come from all over the world to see, buy, and sell computer equipment from the 1970s and 80s.
And to talk about it, of course. There are endless conversations, carried out in a jargon that few non-specialists would even understand, about products that most people living today will never have used. I learn, for example, about the effectiveness of the Commodore Amiga's user interface's cooperative multithreading model, and the competing technologies for self-lubricating dot-matrix printer pins. And so on.
A fascination with early computing equipment and software is hardly a new thing, but retrocomputing seems to be undergoing a real boom right now. There are specialist publications, auction sites, and retail outlets that specialize in supplying the growing market, not to mention the regular exhibitions and festivals. People are restoring old equipment, repurposing it, emulating it, and hybridizing it -- you can buy a kit of parts that will allow a Raspberry Pi to be integrated into a Commodore Vic 20, for example. People are finding new ways to play 1980s video games, and even all-text games like Infocom's Zork series. There's even a small but enthusiastic user group for obsolete word processors like Wordstar.
For the most part, retrocompting is a hobby, but I think that most people involved in the hobby actually work in the computing industry, or are training to. I suppose it isn't unheard of for professionals to take an interest in the historic aspects of their trades -- in some cases this is an integral part of the professional culture. Still, I don't think that professional drivers are more likely than anybody else to restore vintage cars, or nurses to collect Victorian bed-pans. There's something about old computers and software the exercises the imagination of contemporary IT professionals.
To some extent, the explanation is probably nothing more than good old nostalgia. My Sinclair ZX81 never ran very well, but it dates from a time when I ran a whole letter better. Many of us like to be surrounded by the trappings or our youth, however little we may have regarded them at the time.
Still, I don't think that's the only explanation. Many retrocomputing enthusiasts I know were not even born -- not even close to being born -- when the Zilog Z80 was king of the 8-bit CPU hill. Yet these are people who are writing new operating systems to work with home-brew computers based on the venerable Z80. Although it had a remarkable 30-year uninterrupted production run, the original Z80 is no longer made, and enthusiasts take pleasure in scavenging them from old game consoles.
Old computers are not, for the most part, things of beauty, or even evocative of a lost culture, like steam locomotives or duelling pistols.
Nor can it reasonably claimed that old technology is generally superior to what we have now. There are some industries where 'vintage' often does mean 'better' -- I have a wooden tool-chest in my workshop that was made in 1880, and has already outlived several cheap plastic ones.
No: it's hard to conceive of many senses in which a BBC Microcomputer -- amazing as it was for its day -- is functionally superior to a modern laptop. Even a bottom-of-the-market smartphone has a hundred times more computing power than a BBC Micro, and costs -- in real terms -- about a twentieth as much (a Model B cost about £300, at a time when a pint of beer in a pub cost about 30p).
I think the appeal of vintage computers and software is simply that they were comprehensible. You could learn most of what you needed to program a Sinclair Spectrum in an afternoon; in a week, you could learn everything. Things weren't all that much more complicated in the industrial and commercial worlds than they were for home computers -- perhaps software was more involved, and programmers had more peripheral devices to deal with but, in the end, you were working with a fully-documented, reasonably stable environment. In these pre-Web days, any respectable mini-computer came with a shelf-full of printed manuals and, if the information you needed wasn't in there, you could telephone the designers.
As far as software was concerned, either you wrote it, or a colleague did. Even the most complicated program could be printed out in its entirety on a book-sized stack of fan-fold paper.
By comparison, consider what I worked on in my day-job today: it's a message routing system for a large telecoms operator. The part I was working on consists of a number of message brokers from different vendors, connected by a set of applications. The applications use Apache Camel (a Java message processing framework on Spring Boot (an application server and transaction management framework). The Spring Boot applications run on Java virtual machines, which run in Docker lightweight containers, managed by Kubernetes (a container management framework) on virtual machines on a cloud deployment framework on another set of virtual machines, on Linux, which runs on hardware from a dozen different vendors. The applications' logs are collected by FluentD and logstash (log aggregators) and visualized using Kibana (a data visualizer) and ElasticSearch (a search engine). Performance metrics are exposed by Prometheus (a metrics collector), where they are analyzed and display by Grafana (a data graphing framework). Each application has a management agent (Jolokia) which communicates with a cluster-wide administration framework (custom written).
And so on. And on.
And that's not including all the other technologies I have to deal with indirectly when working on this system: TLS and certificate management, relational databases and SQL queries, highly complex build management pipelines, debugging tools, network analysis tools, three different programming languages...
Worst of all, not a single one of these technologies even existed when I started my working life. Half of them did not exist even five years ago. By the time this system is ready to go into service, it will be based on software that is already obsolete, and which nobody will understand five years from now.
Then, when I finished work, I went home and wrote a program in C that displays a clock directly on a Raspberry Pi's display hardware.
Now, I'm not saying I don't understand the technologies I work with. On the contrary, after fifteen years I think understand Java-based middleware development about as well as anybody in the industry. But it's still only a fraction of what there is to know. Maybe, being generous to myself, I might know ten times as much as a raw computer science graduate; but knowing one millionth part of what there is to know is only a little better than knowing one ten-millionth. But in 1985 I knew everything there was to know about programming a GEC microcontroller in GEM BASIC. I could even make repairs to it using a soldering iron.
In the end, this is why I think IT professionals are drawn to vintage computing -- we now all spend our working days in near-complete ignorance. However much we know, it's only a tiny fraction of what there is to know. Modern computer systems and software are based on the work of hundreds, perhaps thousands, of different people, and outside of our own particular specialities, we know almost nothing. It's fairly common in my line of work for there to be almost no knowledge overlap between professional groups -- it's difficult sometimes even to have a productive conversation about system design, because the various stakeholders don't speak the same language, even when they speak the same language, if you see what I mean.
I wonder sometimes whether, say, a Samsung Tab S6 will one day be a collectable piece of vintage equipment (the cynical answer, of course, is "tomorrow"). I suspect not because, for better or worse, people entering the IT industry now are used to working in a climate of ignorance. People no longer even expect to have a full understanding of the technology they use, even as technical professionals. Being bothered by such things seems to be a province of folks like me, who started their computing careers in the days when your PC came with a circuit diagram.
Now, if you'll excuse me, I need to work out how connect a wifi modem to my RML-380Z.