Living Fossils: Old Tech That Just Won't Die

jfruh writes "You might think that flat files, VAXen, and punch card readers are things of the past — and you're right, for the most part. But here and there, these fossilized technologies have found places where they can survive in production use."

Comments

Re:Technology

[Anonymous Coward]

Actually, I've found that people are more likely to be the opposite. They see something new, and they say...well, the old way was better. Old cars, because they hate all these fancy engines that they can't just fix, old televisions because they can't stand those black bars, old light bulbs because those curly ones are too hard to understand.

Too many people assume everything should be frozen at a point in time, because of well, some human factor that results in a resistance to any change or improvement.

Because it might not be perfect, but the old ways, they WERE better.

Don't get me started on the people who think that they're hearing about more murders and killings today, so it must be more than it was back when they were young! Even if you produce statistics showing the opposite, or if you point out the numerous children who survive because of modern medicine, or anything else that shows it's not all bad.

Re:Technology

[qu33ksilver]

Absolutely, never forget your roots. We would be fools to discard our past because that's what led us to where we are now.

Flat Files FTW!

[wrook]

Developers who think that *everything* needs to be in a database scare the crap out of me. Sometimes flat files are a really good idea. Sometimes putting something in a human readable form that can be viewed and edited with a normal text editor is a really good idea. There are many, many things where I don't need to search vast amounts of data, where I don't need atomic commits, where I don't need rollback, etc, etc. For those things I use a flat file.

Admitedly, I know the difference between regular, context free and context sensitive grammars and I know how to write a parser. Unfortunately, this isn't always common knowledge in a software team :-P

Re:Flat Files FTW!

[wvmarle]

I would write a data reader/writer module for the program.

This would handle the data storage, and if later requirements change it's a relatively small part of the program that changes. The rest of the program doesn't have to care how it's stored externally: it just cares about having function calls available to do a read, write, maybe search. This makes it also relatively easy to expand.

And when in future there is a need for say more sophisticated search options, you can rewrite that one module so it starts to interact with a MySQL or Postgres database or so. Even the data format conversion becomes a breeze that way as all you do is read from the old system and write to the new system.

Further in the future maybe your external db goes out of business, and again it's a relatively easy change to a new db.

Re:Technology

[BenJCarter]

The flatfile, like the flatworm, will likely survive eons of evolution...

XML FTW!

Re:Technology

[YttriumOxide]

I get annoyed when people just jump straight to making a database for everything. Sometimes flat files are just a better option, so long as you don't need to run any searches.

Absolutely agreed. My day job is writing software and if I'm storing data that I know will never exceed a few MB at absolute most, has no requirements for search, and is a fairly simple structure; I FAR prefer to use CSV to any kind of database.

The best example is a single application translation table for around 25 languages. 100 strings, 25 languages - it may in theory grow up to 50 languages or so eventually and if the app gets much bigger, up to 200 strings. 200*50 = 10000 strings. At an average of around 15 bytes per string, that's ~150KB of data.

As a UTF-8 CSV text file, I can hand edit it in a run of the mill text editor; loading it in the application takes milliseconds of application startup time (at which point the whole thing sits in memory while the application runs, so it doesn't re-read it again); parsing it is trivial; and any errors introduced somehow aren't going to kill the whole file (perhaps just make one string wrong; or at worst corrupt one language (a single line of the file)). I can't count count the number of times people have told me to convert this to a SQLite database "because it's better"... very sad.