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.