Parables and folklore relating to retrocomputing

Triggered by @cjs’ post about The Story of Jack and Jay I thought that there are probably quite a few parables from back in the day which are worth sharing…

On Holy Wars and a Plea For Peace from 1980. C2 says: “This very influential and amusing classic paper introduced the terms LittleEndian and BigEndian and urged people to stop fighting holy wars over which byte ordering was superior. It is still a must-read for anyone who ever has a reason to care about byte ordering.”

The Paging Game from alt.folklore.computers in 1990, introducing The Thing King. More findings from that group collected here.

The Story of Mel from 1983, all about “optimal programming”, in favour when computers were more expensive than programmers.

Any more favourites to share?


Maybe more an analogy than a fable, the popular illustration of the basic workings of a computer by the example of a clerk and pigeonholes (which eventually translated into the most literal of implementations of the desktop metaphor). The earliest incarnation of the “fable of the clerk and the pigeonholes”, I know, is from the Univac I Manual of Operations (1954) [1], comprehensively depicted by two illustrations found on p.2 and p.6, respectively.


1 Like

Turing’s paper of 1936 also personifies the computer, for other reasons! But no pictures.

…we avoid introducing the “state of mind” by considering a more physical and definite counterpart of it. It is always possible for the computer to break off from his work, to go away and forget all about it, and later to come back and go on with it. If he does this he must leave a note of instructions (written in some standard form) explaining how the work is to be continued. This note is the counterpart of the “state of mind”. We will suppose that the computer works in such a desultory manner that he never does more than one step at a sitting. The note of instructions must enable him to carry out one step and write the next note. Thus the state of progress of the computation at any stage is completely determined by the note of instructions and the symbols on the tape.

Well, Turing may have been unconvential, which is easily acceptable and of no further notice. But this is no excuse for the use of such language as encountered in “state of mind” (no, putting it in quotation marks won’t help) right in the heyday of behaviorism and B.F. Skinner’s reign! :wink:

So I found another one, the Parable of Computer Residents about Digger, Comrade Command Com and Commander Norton (Monitor Magazine, Apr. 1992):

(However, while it may be retro, this may not be the best example.)

On the other hand, the use of the parable has some tradition in computer science, e.g., this parable given by Dijkstra (ca 1973) on trains, toilets and convenient distances to illustrate N^2 vs N/2 and the virtues of programmers:

Although at the time that this story took place, mankind was not blessed yet with automatic computers, our anonymous man who found this solution deserves to be called the world’s first competent programmer.

I have told the above story to different audiences. Programmers, as a rule, are delighted by it, and managers, invariably, get more and more annoyed as the story progresses; true mathematicians, however, fail to see the point.

By this, the parable becomes some of a parable of its own, thus introducing the recursive parable. (Well, it’s Dijkstra.)


While not exactly parables, the AI Koans in HAKMEM (MIT AI Lab memos) / the Jargon File may be considered a subtype.

A Selection of AI Koans: The MIT jargon file version 299

See also, Hacker koan - Simple English Wikipedia, the free encyclopedia


In the days when Sussman was a novice, Minsky once came to him as he sat hacking at the PDP-6.

“What are you doing?”, asked Minsky.

“I am training a randomly wired neural net to play Tic-Tac-Toe” Sussman replied.

“Why is the net wired randomly?”, asked Minsky.

“I do not want it to have any preconceptions of how to play”, Sussman said.

Minsky then shut his eyes.

“Why do you close your eyes?”, Sussman asked his teacher.

“So that the room will be empty.”

At that moment, Sussman was enlightened.

Again, this is a bit of a double-layered affair, since Minsky isn’t just hinting Sussman at a random configuration still being a configuration, but this is also Minsky, who initiated the end of the first boom of neural networks by providing the proof for their intrinsic XOR problem (which was [somewhat; personal musing] overcome by multi-layer networks eventually). While probably not intended by its original reading, as Minsky thoughtfully shut his eyes, there was no network and no preconception, and the (conceptual) room was empty, indeed.

P.S.: Sussman’s TicTac-Toe for the PDP-6 would have been displayed on a Type 340 scope, compare this thread, LIFE - 4 Gosper Glider Guns on PDP-7 Type 340 display

1 Like

Found another collection at the Unix Heritage Wiki which I shamelessly paste here:

Many interviews: Mike Mahoney’s Oral History of Unix

Unix at the `Labs’

Unix in the 1970s

See also: Fear and Loathing on the Unix Trail by Doug Merritt, Ken Arnold and Bob Toxen

(via DragonFly Digest)

And from the same source:

  • Rob Landley about the /usr split.

  • You know how Ken Thompson and Dennis Ritchie created Unix on a PDP-7 in 1969? Well, around 1971 they upgraded to a PDP-11 with a pair of hard drives…

And here’s the Magic switch story:

Photo of the original by Guy Steele (cc-by-nc-sa):

Some years ago, I (GLS) was snooping around in the cabinets that housed the MIT AI Lab’s PDP-10, and noticed a little switch glued to the frame of one cabinet. It was obviously a homebrew job, added by one of the lab’s hardware hackers (no one knows who).

You don’t touch an unknown switch on a computer without knowing what it does, because you might crash the computer. The switch was labeled in a most unhelpful way. It had two positions, and scrawled in pencil on the metal switch body were the words ‘magic’ and ‘more magic’. The switch was in the ‘more magic’ position.

It was clear that this switch was someone’s idea of a silly joke. Convinced by our reasoning that the switch was inoperative, we flipped it. The computer instantly crashed.

Chesterton’s fence from G. K. Chesterton’s 1929 book The Thing (in the chapter entitled “The Drift from Domesticity”):

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”

(Wikipedia:Chesterton's fence - Wikipedia)

I found this used as a parable for a rash rewrite of legacy software, where the original specifications and constraints are unknown.

The same article (“Exit the haunted forest” by John Millikin, Exit the haunted forest – Increment: Software Architecture), where I found this, also mentions the story of Netscape, its (in)famously ugly code base and the ill-fated attempt at a total rewrite, as a parable for recklessly rewriting without need, specifically in the narration of Joel Spolsky (Apr. 2000): Things You Should Never Do, Part I – Joel on Software


The idea that new code is better than old is patently absurd. Old code has been used . It has been tested . Lots of bugs have been found, and they’ve been fixed . There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind of gross if it’s not made out of all new material ?

Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

1 Like