Quoth Silent-Hunter
View Post
Back in the Stone Ages, records were recorded on punch cards. These had a certain width (80 columns; a number picked by Herman Hollerith in the 1880's, and a standard that is still with us today on text-based computer displays 125 years later) and if you went over that width, you needed a second card for every record.
Four digits for the year would have meant two columns less elsewhere on the card... it could have meant truncating the name, or losing two columns for some kind of code, whatever. In that context, dropping two digits of the year doesn't seem like a big deal.
And "putting all the records under one year entry" doesn't work. In addition to only working on records with one date in them, even WITH single-date records, it now means you have to run that many more search operations to locate a particular record if what you are looking for wasn't originally sorted or indexed by date.
Nowadays where a single database is usually indexed on multiple fields, (and, internally, aren't even sorted at all) none of this is a big deal. But for pre-modern databases running punch-card or tape-based data storage, it's a very big deal indeed. And re-computing what indexes you did choose to maintain was expensive. Nowadays, some ridiculous quantity of CPU cycles goes completely to waste. When many of these programs were written, CPU's were kept going at full capacity 24 hours a day, seven days a week... you scheduled computer time days in advance, and had to receive expense approval to use the scarce resource.
If you are some programmer in the 1970's, having the computer record dates the same way you do (few of us use digit years in day-to-day use) is a pretty logical tradeoff vs. a very convoluted workaround. And I expect few programmers at the time thought their code would live that long anyway. In a way, this is all IBM's fault... they've kept complete and total binary compatibility for nearly 50 years on their computers. As in, a program originally written in the '60's can, through a succession of still-available interface adapters, be fed into a machine rolling off the line today in Poughkeepsie, and work without any modification (and not even an emulator!) It would be as if a brand-new Mac Pro could natively run programs meant for the original Apple I. Because writing software is so difficult, failure prone, and expensive, these ancient programs still live on today.
Comment