They Say that Programmers Never Die

They just gosub without return. That is, of course, a joke (with all due apologies to those of you to whom it means nothing), but there’s a kernel of truth in the saying. In their own way, programmers are like authors or artists in that their work can easily outlive them, and their unique and distinct style can be found in their creations: and in that created by those that learn from or imitate them.

This morning I was working on some legacy Perl code that holds together a part of a client’s web site. In particular, I was refactoring the code that displays dates and times in an appropriate format, as part of an effort to simplify the code after fixing a bug that would, under some unusual conditions, use the “pm” suffix for morning times (e.g. 11pm, when it means 11am). Under normal circumstances this would have been a simpler job than it was, but this particular piece of software has been passed from developer to developer, and (until it came into my hands) I’m pretty sure that none of them took the time to understand what their predecessors had done. Several different stylistic and semantic styles are used in the code, and several different solutions are used for the same problem, depending on who was in charge at any given time. In short, the code’s a mess, but the client is on a tight budget and can generally only afford to pay for the minimum amount of work, and not for the sweeping overhaul that the system so badly needs.

I came across a particular line of code, today (evidence, perhaps, of a previous developer looking into a related issue to the one with which I was tasked):

$leu_something .= $hour . " - " . $amorpm;

Even without the developer’s name embedded within the variable name, I could have told you who wrote this code because of its distinct style. Even this single line has a defining appearance of its own, to the trained eye. To illustrate this, consider that the line could equally have been written in any of the following ways (among hundreds of others, without even looking at the optional space characters and interchangeable types of quotation marks used), and would have functioned identically:

• $leu_something = $leu_something .= $hour . " - " . $amorpm;
• $leu_something .= "${hour} - ${amorpm}";
• $leu_something = join($leu_something, $hour, " - ", $amorpm);
• $leu_something .= sprintf('%s - %s', $hour, $amorpm);

Some of these methods have specific advantages or disadvantages, but all have the exact same fundamental meaning meaning. However, even from a glance I could tell that this code belonged to the former developer named Leu (and not any of the other developers whose names I’ve seen in the project) because of the style in which he chose to write it.

Non-programmers often fail to understand why I describe programming as being as much an art as a science. The work of a programmer has been compared to the work of a poet, and I agree with this sentiment. Even merely on a superficial level, both computer code and poetry:

• Can be good or bad (by consensus, or subjectively).
• Attach significant importance to proper syntax and style (you need the right rhyming pattern in a limerick and the right number of brackets in a loop).
• Express a concept through the artistic use of a language.
• When used to express complex ideas, benefit from creative and sometimes out-of-the-box thinking.
• Often lose value if they are literally translated to another language.

Not only that, program code can be beautiful. I’ve examined code before that’s made me smile, or laugh, or that has saddened me, or that has inspired me. I shan’t argue that it’s on a par with the standard of spoken-language poetry: but then, programming languages are not designed to appeal to the pathos, and are at a natural disadvantage. Sometimes the comments for a piece of code can in themselves carry a beauty, too: or they can serve simply to help the reader comprehend a piece of code, in the same way as one can sometimes find guidance in the interpretation of a poem from somebody else’s research.

However, it’s possible to say things with code that one simply can’t convey in the same way, using a spoken language. To prove this point, I’ve composed a short haiku in the medium of the Ruby programming language. For this purpose, I’m defining a haiku as a poem whose lines contain 5, 7, and 5 syllables, respectively. It’s an existentially nihilistic piece called Grind:

def grind(age = 0)
  die if age == 78
  grind(age + 1); end

Vocalised, it would be read as follows:

Def grind: age equals zero,
Die if age equals seventy-eight,
Grind (age plus one); end.

I enjoy the subtlety its use of recursion to reinforce the idea that every year of your life gives you a bigger burden to carry (and a larger amount of memory consumed). This subtlety does not adequately translate to a spoken language.

The line of code I showed you earlier, though, is neither interesting nor remarkable, in itself. What makes it interesting to me is that it persisted – until today, when I removed it – in this piece of software. The author, Leu, died several years ago. But there will exist software that he wrote, being read again and again by tireless machines on a daily basis, for years to come.

I wonder how long the code I write today will live.