Doghouse – Code Longevity

Recently I was discussing with friends how long certain pieces of code have lasted … perhaps not exactly the same piece of code, but a recognizable version of the original that has continued to evolve.

One example of this is the simple text editor.

When I started programming, I used 80-column punched cards and the Fortran language. If you made a mistake, you could stick the bad card into a particular slot on the card punch, duplicate the correct part of the card, and then continue typing to complete the statement. It was horrible, but it was all we had.

The first editor I ever used was on a small mini-computer called the PDP-8. The PDP-8 had 4,000 12-bit words of memory and no storage other than paper tape. The computer had to hold all of the text editor and all of the source code of your program in memory at the same time. You had a paper-driven terminal called the ASR-33 Teletype, and the rolls of paper were expensive, so the text editor tended to print as little as possible. It was a modal editor, which meant that you were either inputting part of your program in input mode or giving editing commands to the program in command mode.

It was also what we called a "dot editor," since an invisible dot controlled where you were inputting data or from where the command was being given.

As an example, a command to print from the beginning of the line to where the dot was would be 0t. and from where the dot was to the end of the line would be .t$. The command 0t$ would type the entire line.

You could also move the dot without the editor typing any output, and there were dozens of other commands for deleting characters, lines, and even blocks of characters.

This simple dot editor was called e. As more commands were added and it moved to early Unix, it became known as ed. Today this editor, like a lot of other Unix commands, might be called "user-unfriendly," but to people used to cards, it was great.

As memory sizes in computers grew, both the editor program and the text that it was manipulating could get larger. The editor's name was eventually changed to em, and then it was introduced to Bill Joy at the University of California, Berkeley. He improved it, and it became ex, which could be used for both hard copy terminals and "those new-fangled character-cell video terminals" in command-line mode.

Eventually Bill Joy wrote a full-screen text editor called vi that still had the modal commands of ex, and vi became one of the mainstream Unix editors for a long time.

The other mainstream editor was, of course, emacs, and these two editors created one of the longest running cyberwars of all time – the arguments of which are best left to another place and time over beer and pizza.

Eventually the functionality of vi was cloned into vim, allowing me to use (more or less) the same text editor for close to 50 years.

Yes, I know that somewhere emacs people are screaming, but I like vim.

Another fine example of a long-lived program is the RAND MH message handling system.

MH was really a series of command-line tools that created a front end for importing and reading email in the early days of Unix. It used the filesystem to hold all the email, so its "database" was very readable and could be manipulated with other Unix commands. I loved using MH.

Eventually email started including non-character data such as graphics and music. Since Unix at that time used 7-bit ASCII characters, an extension was needed to be able to encode the binary data into 7-bit data bytes, and this was called MIME. MH was then extended to handle MIME, and cat pictures began to flourish. On the command line, mh became nmh (new MH).

Eventually windowing came to Unix in the form of the X Window System, and a sort of "graphical shell" was made over nmh called exmh. Later still, Motif (another set of graphical widgets) was added to become another extension of the venerable MH system.

Since MH was first released in 1978 (and I first used it in 1983), it has gone through many incremental upgrades with the last release of the base nmh being in 2018.

Do not think of MH as dead, however, for the sources are still there for people to pick it up and keep improving.

This is the point of this entire article: Free and Open Source invites extensions of good functionality to meet changing needs, and often the code that you think may be dead is only resting somewhere waiting for the next person to look at it and update it again.