Chad Perrin: SOB

4 September 2006

A (late) Solution for the Y2K Bug

Filed under: Cognition,Geek — apotheon @ 08:36

It occurs to me, suddenly, that if all of our otherwise Y2K-vulnerable software had been written in Lisp, the bug would probably never have surfaced as a worldwide catastrophe scare. We would have calmly and quietly coasted into the new millenium without a care for counter resets at 00, with no worries about vanishing credit reporting agencies and airplanes falling out of the sky. Only in extremely pathological edge-cases would the Y2K bug have reared its ugly head.

No, really. Bear with me a moment:

In Lisp, everything (including code) is a list. This is handy for a number of reasons, perhaps most notably because of the code === data && data === code flexibility of the language (whee, macros). The fact that everything is a list, however, is not just a side effect of that, or a foundation for it. It is also a wholly new way of doing things — a comprehensive paradigm of programmatic thinking that does some astounding things for your ability to list, inspect, sort, and transform data (which is of course what computer programs are all about). It’s especially interesting to consider this in terms of dealing with numbers, such as the current year digits in dates.

A list is itself a number, as well as potentially containing numbers. In fact, it does contain numbers, because everything inside a list can be considered a list as well. Consider the following:

cat programming 2006 Seinfeld a 47

Taken at the macro scale, this is a list of six elements. It is, thus, the number six. Delving one level of specificity inward, each of these elements is a list — from the list-of-one that is “a” to the list-of-eleven that is “programming”. Another level inward, the list of eleven characters, “programming”, is made up of eleven lists of one. The first of these, “p”, is syntactic sugar for an ASCII value (or whatever, depending on the character set your browser is using), which is itself a list of ones and zeroes.

Let’s have a look at dates, now. You must know how we got into the Y2K mess in the first place, of course: people were abbreviating the year component of dates before computers came along, truncating them by removing the first two digits. The year 1999, then, would be ’99 on a ledger sheet. People started writing programs that handled the database equivalents of ledger sheets, and in so doing they exactly met the requirements of their project specs when told that to provide useful software that met the standards of the preceding decade’s worth of common practice they must write programs that accepted and provided two-digit years for dates. This was utterly natural, using the common Turing-equivalent programming languages of the time, wherein one would specify how many digits would be used in advance. We only needed two, so we only used two. What could go wrong?

Poor foresight often leads to the biggest disasters when we’re overlooking the assumptions most difficult to recognize as such. On the other hand, if writing all that software in some fairly standard Lisp dialect, the programmers of yore would likely have implemented a system that scaled for the future without thinking about it. After all, it would actually have been easier and more natural to write programs that handled full-length years or, at worst, used arbitrary year number list lengths that just happened to start at two, using Lisp.

I suppose we might just have had a different Y2K bug, then: we’d have the year 99 roll over to 100, which wouldn’t fit into a two-character field on a form. If the programmer of your application was so sloppy as to entirely forgo data validation before moving on, you might have to fix the ledger sheet printout routines.

Your airplane would keep flying, though.


  1. I still remember when 99 was 25% more efficient than 1999 (6 digits to 8), and you could measure that saving of storage space in salaries and year-end bonuses.

    Not to mention few believed those programs will last a decade, let alone into a new millenium.

    Was it avoidable? It wasn’t even premature optimization. If you consider the cost of 1MB of storage in 1970 (hot and cold), take the future value and compare it to the cost of bug fixing in 1999, it makes economic sense.

    What was clearly a mistake was two digits becoming a common pattern, that rolled over from mainframes to PCs. But there’s nothing you can do against human nature.

    Comment by assaf — 4 September 2006 @ 11:35

  2. It wasn’t premature optimization — but it was poorly executed optimization. As I pointed out, Lisp would allow more easily for organic scaling, but that doesn’t mean that scalability in the design was impossible, or even prohibitively difficult, using the more static languages of Lisp’s early days. It just wasn’t the natural way to think about it because of the semantic structure of most languages.

    Of course, making a nonscalable design decision in what turns into a release version of anything almost always guarantees that it will remain that way until it’s too late to plan ahead, and the whole thing must be rewritten at the last second to allow scaling, after years of programming cruft have built upon atop that foundation. Temporary hacks last longest.

    That’s my take, anyway.

    Comment by apotheon — 5 September 2006 @ 12:57

  3. Organic scaling is very hard whan your data is stored in char(6), encoded as 3 bytes, or representation as 2 character spaces in a terminal form.

    In fact, when you’re paid to write (as I was) an application in a language that has good date/time support, and half the code deals with stuffing dates into char(6) (and other space saving measures), I don’t see how changing the language would have affected that.

    Comment by assaf — 5 September 2006 @ 09:40

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License