Slashdot Mirror
Dan Bricklin on Software That Lasts 200 Years
Lansdowne writes "Dan Bricklin, author of VisiCalc, has written a great new essay identifying a need for software that needs to last for decades or even centuries without replacement. Neither prepackaged nor custom-written software is fully able to meet the need, and he identifies how attributes of open source might help to produce long-lasting 'Societal Infrastructure Software'."
I think the subject line says it all. You can't worry about your software working for that long until your hardware can last that long.
~D
Must have had one hell of a beta test phase.
Omnis amans amens
It seems like most open source has been less than 1.0 for at least 200 years. But all for a quality product right? Oh you found a bug? Well thats because its pre-1.0!
To maintain a product you don't need a lot of developers. How can we survive?
No company in the world will ever try and develop software that never needs (costly) upgrades and add-ons. Take a look at Micrsofts behaviour with MS Office, it's a complete cash cow because they can update it when they want and force people into upgrading with changed document types. Even the open source community will be too interested in improving and adding on to thier pet projects to consider leaving it alone.
this article seems pretty flawed.
We need to start thinking about software in a way more like how we think about building bridges, dams, and sewers.
The fundamental difference being bridges cost more to alter than software does. And the capabilities of hardware allows more freedom in software, to which there is no correlation in bridges.
hmmm, just my 2 euro-cents.
With radical new ideas like this the software old-guard must be Bricklin it!
You've probably noticed that people's noses get bigger as they get older. That's because old people are huge liars.
I think the trick is to use simpler hardware, which is easy to replace.
Take todays computer: motherboard with one big black chip, CPU on it, network card also one chip on it, videocard is too impossible to figure out how it works. Due to the integrated design, you can't fix it if it is broken. And in five years you won't be able to replace it one-on-one.
On older hardware (8 bitters), you were able to repair it yourself because you knew how it worked and you know you were capable of replacing a failing chip. Even if you didn't have exactly the same chip, you can use one of a newer family which did the same but would be capable of switching much much faster.
bash$
I disagree. It's got nothing to do with the software but the data.
If the data format is clearly documentented, then it doesn't matter whether the application that generated it is open or closed.
True, you could argue that since the code is open the data format is also documented, but personally I'd find it easier if it was written in a properly structured document.
Otherwise you'd have to resort to learning and then plouging through an application written in some 200 year old programming language (by someone who possibly hacked it up with a hangover at the time) to try and understand what they were doing and why.
Avantslash - View Slashdot cleanly on your mobile phone.
I wonder if there will still be holes/bugs in Microsoft Internet Explorer 6 SP1 in 2204?
:-)
Now excuse me while I get back to writing my "Hello World" application that will last two centuries
vi
For Christ's sake, computers are mostly used as tools. And who keeps their old tools around for so long? Only neanderthals:...
Remember Y2K? Did anyone notice that the world didn't come crashing down on Jan. 1, 2000?
It seems that all those old mainframes running programs from the 60's weren't in such bad shape after all.
This is an over-simplification of course -- people did have to do some work to make sure there weren't any "Y2K" problems.
Constant standards are what is needed to make software last that long.
Language standards don't even last 200 years, how do we expect something as new as software standards to be more uniform than language standards? Language has been around for thousands of years and we still can't agree on that.
The preceding message was based on actual events. Only the names, locations and events have been changed.
We've had software and computers for ~30 years now
Going back 200 years, we only began the proper industrialization and everything was pretty much running on steam.
I think it's flawed to try to design software that lasts for decades or centuries.
The technology is constantly evolving, and as the hardware changes, so does the software.
If the hardware developement continues as it does, in 2200 we, or the people then, might be working with hardware running at terahertz speeds with 4096 bit architechtures.
Probably that's an underestimatement, since the evolving curves tend to be exponential.
I don't really think they would still need the software someone wrote for windows 95 200 years ago.
There are no atheists when recovering from tape backup.
Standards are what must be designed to last for decades, not the software that conforms to the standards. Things like XML, RDF and POSIX will be supported for decades, if not centuries. Who cares if it is Linux running your POSIX apps, or FreeBSD, or HURD? I don't think it matters if software uses libxml2 to parse your XML data, or some yet-unconceived API--as long as it understands XML!
If it is stability and reliable infrastructure that is desired, it is standards that must remain constant and software that must evolve to make the standards work with new technology.
The point that the author makes here is really that without electricity we will lose great parts of recent history.
Emacs is better
/. :))
(mod +5 funny, remember, this is
I disagree with the common comparison of Software to Civil Engineering and Standards Bodies.
Data Structures would be a better analogy, which Standards Bodies have done a really good job declaring. So in 200 years time you'll still be able to read the DVD data format (assuming the media is still good), even though the software that plays it will likely be different.
Software is more like mechanical engineering, where things do break and improvements keep being found. You wouldn't for example use a 1960's car engine in a car today, even though the basic principle is the same. No ones asks why they didn't get it right 40 years ago and aren't still using the same design.
Unfortunately, what would often be considered an early prototype in engineering, is often released as v1.0 -- the cause of which is a long post all unto itself.
Societal infrastructure is the key part here.
;) ) as a matter of fact, EVERYWHERE was very very different
..... Come to think of it - only some things change.
How many democracies are older than 200 years? How many governmental structures have survived 200 years? Bridges may last that long, but 200 years ago, Ireland was a very different place. America was a very different place, England was a very different place (see Ireland and America for why
200 years ago, the Americans loved the french for helping them in the civil war, the english hated the americans as barbarians, the Irish as "Paddies" and the Irish hated the english. The English hated the French
Back to the point - Software, or those parts of it that do qualify as societal infrastructure will have to change, simply to keep up with the rate of societal change and anything that lasts for 200 years is a very fundamental tool indeed.
Johns: Well, how does it look now? Riddick: Looks clear.
See also The Long Now Foundation.
I read their book in college and, though it is a bit pie-in-the-sky, I thought it raised some interesting ideas. One of their projects was to build a clock that could last a thousand years. When I moved to London one of the first things I did was go to see the thousand-year clock in the National Science Museum. There it was, it all it's broken-non-time-telling glory. About a month ago I checked up on it again. Status: still not fixed : \
It is not easy to design a 100year old language
hey, all this babbling about long-term and short-term reminds me of xterm. Soon xterm will be 200 years old. Or at least sooner than almost anything else. (except for getty ;)
#
#\ @ ? Colonize Mars
#
What prevents that from happening is less the state of scientific or technological development - rather it is governed by simple marketplace economics. The call for a "perpetual" product denies the necessity of transactional perpetuation that is indispensible to sustaining the economy. And our daily survival is closely interlinked with this whimsical beast that we all love to loath.
This article is really a call for a change in both the economic and pilitical models that are in place today. I don't know if the author did'nt realise that or deliberately chose to focus on the near issue, but it is an expression of dissatisfaction with the way we do business today.
Which is strange - we routinely accept impossible deadlines in our jobs - deadlines that are dictated by transparently artificial business urgencies.
Makes me wonder what would happen if the growth rate of ALL companies in the world were to be scaled back by say 15% in some kind of economic Slo-Time....:)
On one hand, a deliberate, parity maintained global slow-down might improve everybodys quality of life. On the other hand it might just make things worse and result in a month of Black Tuesdays. And on the gripping hand the offended ghosts of Smith, Keynes and company might curse humankind to be confined to a barter economy for evermore.
See that long UID - that's what you get for lurking too long
The problem with comparing computer practices with civil engineering practices, is the age of the two industries.
Software is such a young industry that best practices, standards etc. have yet to be settled upon and thus will be hard to implement. Most engineering practices have come about after centuries of development, I somehow feel software development will have to mature for a while before we can see similar licences and standards bodies.
There are already legacy COBOL programs that are key pieces of many businesses. Some of those are almost 30 years old. Not really exciting code, but still important to many businesses.
Those Duke Nukem guys should have this problem pegged by now...
davejenkins.com |
The nature of technology is to evolve over time. Only the most basic tools we have haven't changed significantly over time: things like the knife, the hammer, etc. Even the screwdriver has seen significant development in the 20th century (Torx screws, for instance).
Only those things for which the underlying rules don't change can remain constant over time. Software is especially vulnerable to change over time because the platforms it depends on, both other pieces of software (like operating systems) and hardware, change significantly over time. 200 years ago, computers weren't even a glimmer in Charles Babbage's eye.
And as much as technology has changed over that period of time, so have the needs of society. And since software is written to fulfull those needs, it's absurd to even ask it to live much longer than a lifetime. About the only kind of software that could possibly live that long would be games, and even then only a select few have that kind of timelessness.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
An interesting paper, however it's completly idealogical. Consider the IRS's woes with its modernization effort. Also, think about all the mission critical software running on near-end-of-life VAX equipement. Letting software age without proper maintenance and improvement is a dangerous thing.
there is an important difference between tools and infrastructure. true, much software is used as tools--for accomplishing discrete tasks that evolve as societies and technology evolves. but much software--databases, routers, control devices for physical infrastructure, etc--is used more as infrastructure; that is, as a resource expected to be reliable and predictable by many users and necessary for accomplishing other tasks that ride on top of it, including employing new tools.
infrastructure, because of its multi-user character and the fact that other things are designed to work on top of it, has to have lasting standards--if road lanes suddenly start to become half or double the width, then cars, trucks, traffic flows, etc will all be affected. even if some small technical reason might make it be reasonable to change them, their character as infrastructure means that the long term reliability of how they work is more important than short term technical considerations.
in other words, it would probably be silly at this point to try to design user interfaces, web browsers, etc. that last 200 years, because they are still rapidly evolving. however it makes a great deal of sense to start designing standards for data storage and interface, as well as actual 'infrastructure' software to last a long time because more users (including developers of more 'tool-like' software) benefit from its stability than from its instability.
Just find me a customer that wants to pay for "robustness, testing, maintainability, ease of replacement, security, and verifiability" and I'll deliver.
Sure it is possible to write a program that is platform independent and could possible run for 200 years. But the problem is this. How many organizations can last for 200 years without changing their policies or without society changing. Lets compare us Now and 200 years ago 1804. How many companies have lasted sense 1804 not to many. And all of them have changed the way that they did business since then. How many companies 200 years ago would have enough foresight to allow policies for IT workers. Maybe 1 who was swiftly locked away for his crazy talk. Also a lot of todays terminology will go away in 200 year. I predict the term "Race" would be an out dated word confined to the old literature and newspapers, this is because with the steady decline in racial prejudice and inter racial marriages. It would be like 200 years ago a business man will ask you for your religion in order for them to decide to do business with or not, and now there would be some problems even if they asked as just a personal question. Or say we get visited by space aliens, Sex: M F X A I C. Who know what new and unheard of categories will be added or perhaps a method of doing things is drastically changed who even what the company does changes, heck the company I worked for started repairing mainframes, now we do mostly IT Consulting, and that is in 10 years imagine 200 year.
So to make a program this customizable you need to make it a programming language with everything to you need to add and delete change and alter over time. Now even programming languages think Fortran 30 years ago it was the most popular language out there. And now it is tossed aside for the newer languages, even with fortran compilers for linux, most people will rewrite their fortran code to a more modern language then just port it. To take advantage of new features such as GUI, Internet Connectivity, Color Printing, Web Access. More thing that seemed useless or impossible 30 years ago, are now becoming important. Sure it is possible to make a program run for 200 years. But is is possible to make it useful for 200 year. And beside all this extra design time to make a program that can run for 200 years will cost a lot of money and time to do. Are the users of the applications are willing to pay $1,000,000 for a java program that number crunches their numbers. Or will they pay $50,000 for a program that will last them 10 years, and will be a lot less bloated and simpler to use.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I love the way that everyone presents written records as a good example of a "perpetual" medium which surpasses digital.
You may note that the author says "you can read 100-year-old newspapers *on* *microfiche*". This point practically jumps up and down to be noticed - even in the world of printing, paper copies are not seen as suitable for long-term storage, due to difficulties of preservation and physical bulk. So these paper copies are transferred to some other medium for long-term storage. This medium relies on readers existing - if all companies making microfiche readers went out of business (which probably won't be too many years ahead) then the microfiches will be unreadable. And the microfiches themselves are fragile - a scratch in the wrong place will make it difficult to read, and it's on plastic which will degrade over time.
Why should digital be any different? If you want ultra-long-term storage of digital data, use punch holes in gold sheets. Otherwise you use a storage medium which gives you a reasonable storage size and reasonable data security.
On reading the data back, suppose microfiche readers went obsolete and you couldn't buy them. The method of reading the data is still known and recorded, and can be reconstructed by someone needing to get the data back. Similarly, the most common bulk storage methods today are the CD-R and the DVD+/-R (tape backups are practically obsolete). Now the standard for data storage on CD and DVD is, well, *standard*. So if in 200 years time someone wants to read one back, they could build a CD player from first principles.
Grab.
- Move the software to a new box (but similar) since the old one is worn out or not fast enough or
... In practice this is not too difficult since you can either just copy the binaries or buy new ones orThis I would not call a real change and is not too expensive.
- Move the software to a new (or much changed [the current] version of the same one) operating system.
This is expensive as there is a lot of recoding that must be done and then work configuring it on the new platform.
Note that the above is only valid if the software being copied does not really change it's functionality as the customer has not changed the requirement spec.One of the nice things about Unix (Linux/...) is that you can still run very old software on new boxes with at most minimal changes - I still use code that I first wrote some 20 years ago.
There has been much assumption in this discussion that the whole system (hardware, OS, software) has to live unchanged for many years; I think that is missing the point as the true cost of software change is only big in case (2) above.
Note that some software does need to be regularily changed, eg payroll - because the governments change the rules every year or two.
The point is not to make the software run on the same hardware for 200 years. But to make software that still serves its purpose for a long time.
Take accounting: They still use the system they started with. A telnet(or ssh) client connecting to a console or menu based server running the database, the server itself is about 1/10th to 1/20th of the physical size it was first, and the client machines has been upgraded and replaced.
But the old system is still in use because of the speed and usability.
Same with libraries with large databases of their books, they cannot change database and update every year or third for that sake.. It would cost a lot of time and money.. and there is no real point in it. It works!
Mohahah!
...to say that your comment feels more like "5, Insightful" than "3, Funny" to me. Wish I had some modp to give you.
What's needed is ink and paper. It's our proven technology for archiving. Micro fiche and magnetic storage devices are now more prevalent than any time before but the book industry and published journals and daily newspapers show no sign of diminishing. And as the article points out newspapers dating back 200 years are still available in the public libraries. Electronic voting protocol is just now hashing out whether a paper trail is prudent. Granted the article rightly points out the need to develop an archiving industry that is able to meet the needs for computers to replace paper, based archiving but as long as hardware development thrives in an open competitive economy the market will dictate the timing of implementing the necessary hardware. Unless some body like the library of congress undertakes financing the necessary hardware and software.
"Academicians are more likely to share each other's toothbrush than each other's nomenclature."
Cohen
Also, they could just have bought one
It's merely a case of "Betamax vs. VHS" or "history is written by the victorious part". As long as the artifacts/data are retrievable you will be able to reconstruct, but electricity is still the limit.
I think there was a /. post some time ago (that I cannot seem to locate right now) that talked about the freeware paradox: The better freeware becomes the less you make on support.
So, in order to survive I guess you have to make shitty sw and do lots of marketing to sell your products anyway.
Hmm, sounds familiar in some way...
From the article: "most new software and hardware can only access the most recent or most popular old data. (...) The companies that built the software and hardware are often long gone and the specifications lost."
Theres where OSS makes its difference.
In Belgium, notary's still pay law students to copy by hand important documents on thick books, made from acid-free paper and solidly bound together. Stacked in a basement, you can throw a jerrycan of gasoline over them and set fire to it. You will lose (almost) nothing. Instead of relying on laser discs (see other post), print everything out and count on OCR.
10 ?"Hello World" life was simple then
In fact, the Word document format hasn't changed since Word 97. So any Word version from 1997 or onwards will do the job.
.doc file???
.doc changes between different archs (MAC, X86...)
And changing the settings to saving in RTF format by default (enabling Word versions from Word 6.0 through 2003, as well as basically all other word processors, to read the documents) isn't all that hard. Not even in a corporate setting.
What? do you think your brand-new Office XP will flawlessly read your 10 years-old Word 2.0
just googling a little bit shows that you are not right
Not to mention
So...
Microsofts encourages upgrading of Office installations through a lot of questionable means, but the Word document format isn't one of them.
It IS another of them
I've yet to meet a client commissioning a project who knew well how his own business operated, still less was able to understand how any knowledge he did have might be usefully turned into a specification. One of the reasons some software projects have a short life is that the intended users fundamentally misunderstood how their business worked, or that its way of working was likely to change.
I totally agree with the author, but i think the world is just not ready for this. I've had some really futuristic toughts while reading the article (one tends to have those when reading about things that have to last for 200 years)
:-)
Until society is less about profit, i don't see such a thing happening... open source might be an answer for this but it won't be enough. There would have to be _more_ open and globally adopted standards and this won't happen very soon (again... profit)
Take the positive things out of futurama, 1984, bill and teds bogus journey, total recall, or any other futuristic story with an 'evolved' society and we might get there...
I recently read a reply stating the 60's mentality... the fact that technology will have to work for us as it evolves, though nowadays we still have to work for technology too much
heck... we still have to work! i'd better get back on that before i write a complete article about this subject
Software that lasts forever is the simplest kind.
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
The idea of software that lasts 200 years reminded me of a discussion on the radio the other day about the origin of a joke: "I've had this broom 50 years, its had 5 new heads and 3 new handles". The identity issue played with here dates back at least to Plutarch's Ship of Theseus - if you keep replacing parts of a thing, until no original parts remain, is it still the same thing?
The relevance to software is captured with an example: Is Linux still Linux? How much remains of the kernel originally published by Linus? Would would you say that Linux has been around for X years (pick X to suit)?
Most people would agree that it's still Linux. What Linux, the broom, and Theseus' ship have in common is that they could be modified to meet the demands of time, while retaining their identity.
I've always thought that maintainability is the highest virtue software can strive for, above other quality-oriented goals like being bug-free, or performant. If its buggy, but maintainable, it can be fixed; if its slow, but maintainable, we can make it faster. I think it could also be argued that software, like Theseus' ship, needs to be maintainable to last 200 years; but the version 200 years from now may not resemble the original in the slightest.
Just my 2c
Baz
See the BBC Domesday project for a good example
BBC Domesday project
I'm a rabbit startled by the headlights of life
Wait... what do I care. In 200 years I'll be dead.
Evolution or ID?
You both suck. The correct answer is NotePad. DUH! FOR GREAT JUSTICE!
- TeX user manual
- TeX commented source code
- Metafont user manual
- Metafont commented source code
- The Metafont programms to generate the computer modern fonts
What is that good for?If you, say in 500 years, get a copy of these 5 volumes (and if they are printed on good paper, there is good chance that these survive). You just need some kind of computing device and the skillset to implement some easy pascal like programming language. Then you type in the programms and fonts from this book and voila, you have working a TeX system!
Of course you need to write a .dvi driver for whatever output device you want to need and have at that time.
If you now find some .tex source of one of Knuth's books, be it in print or some crude hyperflux memory cube, you are then able to reproduce that book in the quality Knuth intended it to have!
Thus TeX is explicitly developed to transfer the typographic quality of Knuth's books into the future, without depending that lots of software vendors establish lots of data format (e.g. Word 2325 to Wort 2326) converters!
Regards,
Marc
or is everyone else sick and tired of these old computer visionarys coming down from their 42nd floor penthouses to spell d00m upon the current state of computing?
I am too lazy to log in.
I think this software package, NASTRAN, is possible one of the few that could last that long. Finite element analysis is incredible useful. This software, written in Fortran, has been around since the 60's.
Also, Spice has proven to be incredibly useful. It even has the ability to model superconducting Josephson's Junctions.
These types of software allow us to explore and create new products/ inventions. Truly, applications that help advance knowledge are more likely to stay around.
If you want a good example of survivable software and data, just look at the emulators for old 8/16bit computers, e.g. the Commodore 64 emulators. They faithfully reproduce the entire machine, allowing any of the old software to be used without a problem. Even in 200 years time, these old C64 emulators will be around as a curiosity, in the same way that early "flip card" cinema machines are found in museums.
I mean: I would deliver too. However, dear customer, you have to wait till 2204 before it's finished. But that day, it will be *perfect* (bugs excluded of course) Ah, yes, and payment in advance please!
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
Dan is right, there's a real need for societal software, and somehow it will exist in some form in the near future.
The problem I see is simple: in other engineering areas standards are used everywhere, ie: electrical normatives regulates every aspect of an industrial device. Software (at least in his current form) cannot be 'normalized' to that level, and that's the problem.
We can agree on 'simple' or 'closed' things such as data formats, or even on classical algorithms but how we stablish the other details of source code making (ie: variable names, allocation strategies, etc,etc)? And even more important, if we try to normalize those aspects how long will or those norms lasts?
What's in a sig?
I don't know if media formatting is really part of the problem. My brother only exaggerates slightly when he says he has never deleted a file in 20 years, because his PC disk is always getting bigger. Your data should get copied at regular intervals if you want keep it alive. You will copy it even if you only do that when you upgrade your machine. If you don't, then magnetic media will slowly degrade, CD's may craze, punched cards may get used for shopping lists. If you still have the original text of your PhD on 1/4" tape, then it is probably not readable even if you could find a drive.
When i design projects, i tend to think more about keeping the data clean, simple and robust over time, rather than the ease which certian applications can reproduce it.
For example, when i designed KML, the idea was that it was meant to be a robust format that could be defined outside the context of any word-processor, and ultimately aimed at HTML, TeX, etc. At the moment, it is Regina REXX's job to render my markup. Nothing stops this from becoming Perl's or CEnvi's job! It's just a matter of writing a new parsing engine.
Because it is not something like HTML or TeX or RTF, i have considerable control over the format, and i can map several internal styles onto the same output, eg like {emphasis} vs {bold} in html. But the thing can be to the structure of the document.
It is more data standard, rather than program standard that is important. The latter is also important, since we don't want to either run dusty decks or old programs.
But what can you expect from an upgrades-driven market?
OS/2 - because choice is a terrible thing to waste.
What the author did not mention is that software implementations are always just a projection of a solution using current technologies.
As long technology advances, the most efficient implementation (in software and hardware) will be drastically different than the previous one.
If we take the time-machine and a current software (ie Linux-KDE or Eclipse-IDE) and go to 1980 and release it as a brand new OS or IDE do you think that will be succeeded ?
I strongly doubt
public class HelloWorld
{
public static void main(String[] args)
{
System.out.println("hello world");
}
}
That should last you a few hundred years.
I would argue that you shouldn't put too much effort into making software that you think will last 200 years, because in 10 years time, you'll find that a technological change completely invalidates fundamental design/architectural/etc assumptions, and thus your software goes out the window.
:-).
The best you can ever do is write software for a shortish horizon, i.e. a couple of decades or so.
I mean, if anyone could predict what software would last 200 years, then please contact me because I want your help in betting on the stock market
Technologies change, either incrementally, disruptively, etc. One quote I remember from Lucent was "we knew the internet was coming, we just didn't know that it'd be like this". Who can predict that a specific protocol, or a specific topological approach or a specific standard will be the direction of the future?
Designing for 200 years lifetime is basically science fiction: possibly interesting and entertaining, and illustrating some moral or technical dilemas, but ultimately to be obsolete when the real future comes around.
What about the year 2038 bug? 68 years may have seemed like a long time back in 1970, but it's getting closer, and if there are still a lot of old unix systems/programs running by the mid 2030's there's gonna be a lot of problems.
There is still the problem that it uses our current language and characters, so you need to know at least one language to figure it out.
I think creating an abstract communication bootstrap procedure would be fun, if you want to start such a project, please reply or email me at d31337(di4g@ch33rful.c0m)(or see homepage).
I'm still trying to figure out what people mean by 'social skills' here.
Comment removed based on user account deletion
That's the first reaction this guy's getting from people I bet. Just remember my favorite quote from Captain Picard: "Things are only impossible until they're not!"
You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!
'nuff said
Sanity is the trademark of a weak mind. -- Mark Harrold
Which platform should we use, the one that goes out of support in four years or the one that has daily kernel releases?
I cant think of any intelectual property that has lasted 200 years. for that matter, I cant think of many bridges, dams, or sewers that have lasted over 200 years without some sort of upgrade. This guy seems to be in fantasy land.
Many posters above have said that as long as something is documented correctly, in other words if the standards are open, then software will be long-lived.
The above is wrong, because software does not only consist of data, but of algorithms, too. Algorithms change as technology changes. Therefore, what matters is the interfaces, not the actual standards. An interface expresses a standard, but a standard can not express an interface.
For example, if every computer had the same interface for reading a BMP file, we need not be concerned about the BMP format; but the reverse is not true: we have the BMP format, but we don't have the interface to read a BMP file.
But how are interfaces specified ? is there a uniform language to express interfaces in software ?
The simple answer is "no". We have specifications that define interfaces, but those can't run as software yet. We have XML, but XML does not define interface behaviour, only a structured data format. And we have a myriad of programming languages, all defining their own interface to software.
In order to have long lasting software, even for decades, we need to have a mechanism of defining software interfaces, that works on binary level, can be used across distributed environments, allows incremental change of software, it is persistent etc.
In other words, we need a distributed object oriented persistent information system.
The Long Now Foundation: 10,000 Year Clock and Library Long Now is the brainchild of Stewart Brand.
-kgj
-kgj
...bring back paper tape!
better yet, fetch me a case of punched cards!
I know that this is centering more around commercial programming, which is much more generic than custom programming.
But normally, for custom programming work (ie, trying to solve the needs of a specific company), I'm lucky if the requirements stay consistant through the development of the project. At one place I worked, it wasn't uncommon for the management to change significant parts of the project on a weekly basis -- at one point, they kept flip flopping on two major components for about a month... then they get pissed off when we're behind schedule to meet a deadline that the technical staff said was unrealistic in the first place.
His specific examples were in regards to data storage for the most part, which has entirely different design requirements than your basic calculator application.
Oh -- and I've gone back and opened up 15+ year old files... but typically, I have to do it older hardware, especially in the case of old PC software, where the current hardware won't run an OS old enough to run the software correctly. Hopefully, these issues with help to drive the emulation market, so we can just emulate the Apple ][e to run Quark Word Juggler or whatever else we might need.
Build it, and they will come^Hplain.
What makes anyone think that the applications that we seem to need today will even be useful 200+ years from now?
Society -- and its needs -- changes constantly.
No vi is correct, the article is about software, not operating systems! :D
Music is everybody's possession.
It's only publishers who think that people own it.
Fuck Beta
~John Lenno
you want mylar tape, like the old machine-shop CNC programmers used. Design a program, punch it to paper tape, test; if it works, punch a mylar version. Unaffected by shop liquids (coolant / solvents), not easily torn, etc. That's the archive tape.
Imagine all those space/asteroid probes we will be sending out, assuming it will come back only after centuries, 'll need software that works for centuries and software on the ground station that remains compatible with it.
what about historical data, would we have to retrieve/upgrade all digital documents just to make sure that it remains compatible, couple of centuries from now.
I'm bequeathing all my asteriods in the alpha-epsilon nebula to my great great grand children in a will written in Word, after all.
It's been done... there were a lot of the players around for a while, and the hardware was a little bit more durable than a modern PC. The data's been rescued, and these people have made good progress on software emulation of the original hardware. The big problem is the plethora of potential copyright owners making the disk not legally copyable or distributable...
Since it's public release in 1987, every new release of the display servers has remained backwards compatible to remote networked applications going back to 1986. That means that you can have a 1987 Unix server running an X application, behind an internal firewall, networked to any modern X display server on any desktop OS you care to name. It is the only graphical network protocol in current use that has remained backwards compatable. X11 display server vendors are not going to break that backward compatiblity
Building remote network X11 application servers has proven to be the most future proof, vendor independent and secureable route.
Data formats should last 200 years. Hey I'd be happy with a decade.
The application itself is almost irrelevant if that were the case.
I am very small, utmostly microscopic.
In A Deepness in the Sky, Vinge posits a collection of software of ancient origins that handles all of the Qeng Ho's automation. This software is never replaced, but simply evolves as better ideas appear. While not technically open source (the Qeng Ho considered this software to be one of their proprietary advantages), it is open to every member of the group. By the time of Pham Nuwen, it had existed in some form or another for literally thousands of years, and over that time had been inspected by thousands of people.
[ home ]
Go into a nuclear power station (make sure to wear your I Am Not A Terrorist shirt). You'll find VMS/VAX machines running software that's gone decades without an error or reboot. Old news.
If you were blocking sigs, you wouldn't have to read this.
See, this happens when you use 200 year old speech recognition software...
...I agree heartily, but were the United States is concerned, this will probably never happen. The brand of capitalism that currently drives the U.S. is not friendly to goods and services that are expected to last a long time. In the past, you could buy a TV and the company would guarantee it's picture tube for up to ten years. These days you're lucky to find a TV with a five year guarantee on the picture tube and in most cases you are forced into buying an extended warranty that you have to renew.
The way that homes were built in the early part of the 20th century, those homes could be expected to still last up to 100+ years. These days, the cheap 'lick em and stick em' jobs that people pay hundreds of thousands of dollars for are certain to start falling apart in 10-25 years. I know this because I used to work on some of them. The materials are not meant to last. Many of the homes develop probles with the plumbing, roof, even the electrical in some cases. A lot of these homes can't stand up to tornadoes as well as the old houses could. There was a neighborhood in a city south of me where all the bran new houses were torn apart by a tornado. These houses were built in the late 1980s and 1990s. Within a few blocks, there were a few old farm houses that were unscathed. My point is that houses these days are made of crap, more expensive and are not built to last. They are essentially disposable after one generation grows up in them (while having to fix problems).
This is all evidence of the disposable, recurring payment culture of the U.S. today. I exclude other countries even though many of them have the same problem, but to a lesser extent. Those other countries are fr more likely to try and build a long-lasting, open source infrastructure. When I was a kid in the 70s, recurring fees were rare other than utilities and mortgage or car payments. Today, you can get nearly anything for a recurring fee. Although all the fees themselves are small, they total to whopping bills if a person needs or wants all those goods and services. Whatever happened to the day when you could buy something and it was yours. 100%. No strings attached. No recurring fees. Just yours. Sure there are a few things, but keep in mind that recurring fee or not, they are not built to last. Durability is anathema to profit in the new American way. The idea of having long-lasting, open source/free software is going to have a lot of opponents in the American software business soley because there is money to be made.
Un-news
A long term solution might be to also make the hardware opensource (release it under the LGPL), which is already done by some people. This makes a difficult design simpeler to understand. More hardware standards would also help...
I'm not sure that todays software is at the level where we can simply "maintain" it to fit and work with newly emerging software. Today's most prolific form of "maintenance" might argueably be software patches. We have all seen the effects of daily patches to common software and the problems that this approach brings about, (::cough:: ::cough:: Windows.)
Sure, you can have software that lasts 200 years and doesn't need to be modified, but the tough part is to make it interoperable with tomorrow's technologies. We're making great progress with data formats and specs, (XML, webservies, etc...) but we still have a long way to go... I personally don't think that today's software can do this.
A lot of software is quite useful, but written in scripting languages like Python or VB and is thrown away and forgotten once it's accomplished its task.
Other software embodies important fundamental operations, such an FFT or LU factorization. You'll still find a lot of useful scientific and mathematical software in the SLATEC library that was developed two decades ago that will compile using g77 on any Linux box.
The bottom line is that there is a need for all kinds of software ranging from the throwaway script to the eternal algorithm: they're all useful.
"Provided by the management for your protection."
In A Deepness in the Sky, Vinge posits a collection of software of ancient origins that handles all of the Qeng Ho's automation.
If you calculate the offset between the starting date of their oldest calendar and the epoch date of their software, it seems that their software is based on something written in the '70s, or at least that's when its calendar started.
Things that make you go hmmm...
Rather, it's preservation of *Data*. If data were preserved in a readable format for future machines to read, parse, and manipulate using their own software, then we would not have to worry whether our data for 2000 is readable in 2021.
I suggest the best way to preserve data might be optically-readable text characters on microfilm, or acid-free paper, or metal, or all three.
Nyekulturniy... Proudly confusing readers and editors since 1981!
That's not to say that the change wasn't needed, as it was, because of other problems, which we started discovering during the course of the project, but then again, they never should've gone to the software they were running in the first place, as it didn't have a benefit/cost ratio better than the software they were on originally.
Of course, we also went through 4 different PMs on the project, had 'co-project managers' at one point, and I'd get bitched at for bringing up flaws in the project plan, even though I had been told in the first meeting that I was the technical oversight, and if something went wrong, it'd be my fault.
From my experience, a good project comes when the programmers know what the goals and objectives of the organization are, and are then told what their constraints are (budget, time, etc), to make it happen. It rarely comes when the higher level mangers decide on the solution, and then tell you how you have to build it. For some reason, I got yelled at after putting up the following sign in my cubicle:
Build it, and they will come^Hplain.
"Dan Bricklin on Smoking marijuana"
Their web site has been mostly broken the past two years. No one seems to maintaining it.
They built a clock prototype, but the overall project seems to be moribound.
I expect FORTRTAN and COBOL to be around in some form 200 years from their invention cira 1950s. :-)
(I'm not sure whether this should be mod funny or tragic
Another problem is the advent of the GUI. Give a user, or even a programmer, a text-oriented application today and be prepared for much wailing and gnashing of teeth. As someone who started writing programs on mainframes, it doesn't bother me, but I've seen users look at me like I'm some kind of Martian when I give them a command-line program to solve a problem, even though it is supplied with step-by-step documentation on how to use it.
Where are we today? I don't believe that there has been much progress made in recent years. You can write portable programs in COBOL, FORTRAN and Ada. ISO Pascal and ANSI BASIC seem to be near extinction. Portable programs are theoretically possible in C, but the pitfalls and temptations are many. I'm not a database programmer, but I would hope that there is a portable subset of SQL that would support the portable use of RDBMS. Why should I know or care that the system is using Oracle or SQL Server?
Mea navis aericumbens anguillis abundat
I used to work for a rather large telco-datacenter. They were using software built in 1970, to provision internet connectivity.
Telnet in (pick a username and try PASSWORD for the password) 75% of users were set up with default passwords. 50% of the active users were employees who left the company several years prior.
My team coded a new system from the ground up. Taking into account all the changes in the past 30 or so years. It was large roboust and elegant. Anyone who used the old system was completely blow away by the new system... Except the lead consultant from Accenturd. After 5 mins of our hour presentation, he cut us short and went on to be little us.... "anyone can code", " its just a website", ya know your company hired US to do that FOR you.
In the end accenturd decided that our 30 year old system would be just fine with a few modifiactions.. Sure the old system needs a team of 60, vs the team of 6 our NEW system required. But thats of little consequence.
$1 million - accenturd charge for simple modifications to a 30 year old system.
..VS..
Free ground up system built by internal employees, who worked with the old system on a daily basis.
The final descision was made by the person who originally spent the $1 million to accenturd. Seems he didnt want to admit he wasted $1 million for something we coulda gotten internally, for free.
There is no reason code should be running 30 years. I can assure you the original developer never intended 30 year life cycle on his code.
Old code still WORKED, that coder impresses me.
Old code was way obsolete, managment depresses me.
WrongWay
I don't know whether operational software can last that long, but vaporware can be very durable. Ada Lovelace wrote vaporware that is now almost 200 years old and still going strong.
And it's really a 200-year development cycle.
Come on people...
Rewind 200yrs. Has society stayed the same? Have there maybe been one or two changes in the basic structure and function? New laws maybe? New organisational bodies?
Not only does technology change but society does too, and faster by the decade.
This story is just dumb.
217 years and counting.... of course, it's had 27 patches applied to it.
Sometimes seventeen/Syllables aren't enough to/Express a complete
It applies in two areas:-
to the data (and means to handle it) of patient records, which need to be preserved workably for around 100 years + the age of reproduction of the next generation, which is near enough forever now.
to the medical logic modules. If we keep starting again we are not going to accumulate the rules and templates that are needed, instead we will keep generating the same sets of the obvious ones, again and again.
And paying for the smae thing agian an again.
http://www.oshca.net/ Open Source Healthcare Alliance is quietly encouraging some of this.
Open Source may be open, but in my experience most of it is far, far too complex--and undocumented--to truly be considered open. Yes, closed source is usually complex, too. Some reasons for this complexity:
1. Inappropriate language choice, usually using systems-level applications to write applications.
2. Inexperienced programmers. When you're 18 you don't know much about software engineering. There's the fundamental issue that who wrote the software can be just is important as what it is supposed to do.
3. Computing culture that reveres complexity.
The foundations of our mainframe ERP package are basically almost 30 years old, only having needed a recompile when moving from 32 bit CISC to 64 bit RISC hardware a couple of years ago. Only last year the last customer who was still using our code from the seventies finally upgraded to the latest version, finally ending our need to support it :)
If it lasts 30 years, why not 200?
"dedicated enthusiasts were desperately trying to assemble a working laserdisc system, in order to archive all the data collected just 20 years earlier."
;-)
Send me their phone number. They can have my barely-used laserdisc player, if they agree to transcribe all my laserdiscs to Blu-Ray dual-layer DVD for me.
We don't need binary compatibility to keep a working interface standard alive. Consider UNIX. From Version 7 on, the core system calls of UNIX have not changed, and the differences between V6 and V7 are not major. Every major operating system in use today implements a superset of the V7 core API, including the arch-"anti-UNIX" Windows.
This is proof by example that interfaces can remain stable long-term without a significant formal standards process or hypothetical "persistent object-oriented" operating systems. Expecting a binary API to remain current over 30+ years is naive, at best. Consider a binary API created in the mid '70s. What would it be facing now, with desktop and home computers containing more RAM than the most advanced OS of the time could have addressed? It would be the "time_t problem" multiplied over and over again throughout the ABI.
Would you be completely comfortable having a conversation in the colloquial English of 200 years ago?
;-)
Now, imagine trying to understand the coder's source-code comments [*cough*] of 200 years ago.
The fundamental difference being bridges cost more to alter than software does.
Which is directly correlated to the degree to which people care when one or the other comes crashing down.If a state, federal, or international root-cause investigating committee with subpoena powers was impanelled every time a piece of software crashed (like they often do for a bridge crashing down), Red Hat would be out of business in three weeks, Apple in two weeks, Sun in under a week, and Microsoft inside thirty-eight minutes.
Dan Bricklin is proposing a class of software with a substantially different attitude. IE, software that the company maintaining it says: "As long as you pay this fixed-cost support contract, we will guaranty to support this exact software package for up to 200 years, will let you shift between and use your licenses on any and all hardware/OS combination no matter how different they may be from what you have now, will make sure it remains completely usuable by any C-average high school graduate after six hours training, will be liable in a civil suit if it should ever crash, and will help you migrate your data to any product from any comptetor you may decide to use instead... although we suggest you get matching terms." (Try asking your favorite software vendor for that and see how long it takes them to stop laughing.)
With software requirements like that, the cost of making changes to the software becomes very comparable to changing the bridge. In fact, the bridge is probably a lot cheaper.
[T]he capabilities of hardware allows more freedom in software, to which there is no correlation in bridges.
Sure there is! Oh, wait, you care about whether your bridge won't come crashing down under use. Oops. Well, then....
//Information does not want to be free; it wants to breed.
"No company in the world will ever try and develop software that never needs (costly) upgrades and add-ons."
;-)
And no open-source developer is going to care about having "street cred" which lasts for 200 years.
Why?
Society changes, why do we want software from 200 years ago to work today.
Hell Hardware changes so damned fast. Moore's law or not.
Making something "just work" for a long time kinda kills inovation. It's when things "need" to be changes or upgraded that new ideas come along.
The author describes a lot of what's wrong with software development right now. Being on the admin side of things, I've often had to deal with very buggy stuff custom-written by an internal IT department. Lots of key systems at large companies are still running on either the original hardware or upgraded versions of the platform. (There was an article a while back about VAX finally being killed by HP...that should tell you something.) Any improvements are hindered by the original framework (think screen-scraping apps, multiple file format translations, etc.)
Civil engineers also run into this problem. For instance, take any large city whose highway system was built more than 50 years ago (NYC and Boston come to mind immediately.) No one ever dreamed that everyone would have their own car and stop using the trains/buses/ferries to commute to work. Therefore, overcapacity was never seen as a problem, and the rush hours just get longer every year as everyone tries to stagger their commutes. And since the roads are right next to buildings, in-place upgrades are very rare.
I think that once the whole IT labor market shakes itself out, software engineering will become another branch of traditional engineering. Just like power plants, dams, airports, etc., we're now dependent on computers, and it's time to put some standards into place. Software needs to be built such that it's portable, easily understood by a similarly-trained engineer, and conducive to improvements. In other words, it needs to be able to outlive the coder.
Um. Welsh?
Latin? True, there are corrupted, debased forms around, but there's still the real thing too.
//Information does not want to be free; it wants to breed.
There is a software and hardware system that my company is designing to be maintainable until 2048. It has a long and well funded development cycle. We are developing version 6.0. Its funny though, the product has only ever been tested since we developed it over thirty years ago. And the design goal is to make it so well and in such quantity that it is never used. What is it?
Do you also program in COBOL?
I have an ink and paper collection of books and magazines going to 1855. Today, most of the cheaper works, like pulp magazines, start getting brittle at 25 years old. Magazines older than 50 take real care in reading, my dad's 1950's and 1940's Popular Sciences rip easily if handled the way one handles new magazines. Paper lasts longer than most software, but not much.
Lisp is about 50.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
If the data formats are standardized it should not matter what kind of hardware or media is used, the data just migrates from one technical platform to another.
I firmly believe that without this we will lose a significant part of our history. Current history is known because of durable "storage" like paper and fossiles, stone tablets or murals. The materials are all degrading but last longer then something digital.
If we keep on trusting on technology we use right now we would be very lucky if anyone in the near future would be capable of finding anything significant which would be representable of our time. All our information is being recorded in digital format. This includes important things like presidential speeches, signed documents etc.
This society is more and more dependent on electronic information. Alot of information isn't available in printing anymore let alone in a true durable format. If for some reason there will be some major catastrophy any survivors' offspring in the future will know nothing about this age and it's mistakes and would not learn a thing about it.
We had the opportunity to study history because of the durability of it's information. Our information, however, doesn't even last a lifetime.
if he thinks ANY software could last a century or more. Or even SHOULD so last.
HUMANS won't last through this century! How does he expect software to do so?
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
How can you design a software that will last 200 years. Computing is making leaps and bounds annually. There is no feasable way that software written today will be useful in 20 years let alone 200. Think of the 5 1/4 floppy software. How many people here still use those programs? With CPU archetectures and memory optimizations, code written at anytime will be obsolete in a matter of years. Whose to say computers will continue to use the same hardware even? Techies have already made a switch from a single molecule, how is your code going to run on a CPU made up entirely of individual molecules as opposed to a printed ciruit?
I am Bennett Haselton! I am Bennett Haselton!
You don't need the hardware to last.
This issue is a bit more complicated than you think.
This guy is my hero. It's because of the concept of the electronic spreadsheet (delayed-evaluation functional programming for the masses!) that computers are where they are in business nowadays. Anyone can write applications that used to take cobol'ers in the past.
Spreadsheets have empowered more people to fulfill their vision of computing than any other tool in the industry's history.
We need common, uencumbered data formats. XML might be key here.
Anything simple and extensible will do, so any features slapped onto the future applications that deal with the data maintain backward compatibility almost forever. This shouldn't be that hard to accomplish.
What's really holding it back is, once again, the paradigm that Microsoft pioneered. "We came up with the format, so if you want to read this at all--PAY UP!" This makes communication with the PRESENT difficult, much less pereserving information for the future.
There is a lot of information flying around the Internet. Useful, factual information. But it's sometimes useless for research because the Internet is so ethereal. There's nothing consistent to reference. A news article will be there one week and gone the next. We need two things: First, we need software (or data, anyway) that will survive format changes into the 23rd century. Second, we need a reliable, academically recognized repository of information published on the Web.
Software is linear by nature. The Universe is Curvelinear. The only way that we could apply Dan Bricklin's idea is to go into the future that is going to exist, lets say in 200 years, and bring that software back. If only it weren't for that whole space-time-continuem thing getting the way...
Software however written is capable of running for as long as it is viable to the market. It's not an issue of hardware or interdependency between software sources. It's that our market and general theory of technology is destructive/creative in nature. We rebuild software not because it isn't capable of running for centuries but because the users of that software have been emboldened to think creatively about new applications. Our clients could run the software they have for a long period of time. We build platforms that support 5-10 years of enhancement. But the market whether external or internal requires us to innovate rapidly. To create software that last centuries you would need to kill the creative process that is technology. The social process that defines us as humans.
Sounds to me like he would be a proponent of Java, because of the JVM and the ability to run on any hardware/OS. The storage for the data could be anything, the programming, platform independent, because the JVM can be made to run on an machine and therefore, be moved if/when necessary. However, that's nice for the front-end, but it would have to also apply to the back-end, where the data storage is. Client server architecture would throw a wrench into the situation, but it also may help it. Keeping an old legacy system in the back, maybe made of clusters to allow for expansion and easy replacement, would be ideal. And, the client end could be ugpraded as the years go on to allow for new technologies.
Seems silly to me when you consider even human language has changed so much in the past 100-200 years. Just think what it will look like in 100+ years. If you take any novel or movie today, aren't they just rewritten rehashes of plots that have existed for the past 1000+ years? Important software, like important ideas will be maintained, migrated, changed, morphed and improved upon. The really bad ideas will hopefully decay out of existence. Really, who the &$^% cares what was in our Oracle DB 100 years from now?
Some of the feedback I'm reading brought to mind that many are too close to the issue. Step back and think about a situation where the problem becomes how can this function and the data used or the data generated be useful today and 200 years from now?
Unless you're talking about a fundamental change in human interaction and use of technology, it isn't out of the question that data on a [say] spreadsheet today might have a use 200 years from now. The data is what is important, not the file format or the storage media.
Can the circumstance be engineered that would allow a historian access to that data? Look at the scope of the issue - file format, storage consistency, content validation, and so on; But, think in terms of 200 years from today.
Mod me troll, if you must, I can't help it.
In the UK we keep a cradle to grave medical record, until relatively recently in an A5 sized brown cardboard packet named after Lloyd-George. "Socialised medicine" (except he was a Liberal, but never mind) However, wherever the record is, and however it is formatted, the people _holding_ it have a need to keep it usable for as long as I said for use, or a shorter time but still often > 25 years for leagla and other uses. Are you not in the midst of a programme to connect your medical records even now?
What you are saying is also valid if the standard changes. If 'time_t' goes from 32 to 64 bits, then all software needs recompilation.
But if there was an interface, let's say a class 'Time' where it was specified and known across all systems, all we would have to do is change the internals of this class from 32 to 64 bits.
(and if the system consisted from persistent objects, instead of monolithic pieces of code, we would just have to change all the 'Time' instances in all applications, automatically, using a script).
Interfaces are what matters, not standards.
I take a bow to the report and the author.
Being a computer programmer, I wouldn't call myself a 'Software Engineer' due to the appalling state of writing software in its current state. There has been for quite some time this in-bred mentality of Versions, that nothing is ever finished, mostly driven by commercial greed - despite the huge advances in computer power, our OS'es and their applications are still struggling to keep up with an Amiga, for chrissake.
Moreover, it can have lethal consequences; for example, radiation treatment, or airplane control. Deaths ensued. "Sorry that your college outing ended in all their deaths, we were running 1.1.3 of the aileron system."
Sure, even mechanical engineers get it wrong, but their main onus is to make something that will work, not, as in the software case, 'get it out now, fix it later'.
So, if someone says they are a 'Software Engineer', ask them, what is it they do that merits the 'Engineer' tag - would they build a bridge that lasts? Nope.
The language of choice for the 200 year old software project will be COBOL. Hey, if you want your software to last, you obviously need to use a language that, despite the best efforts of trained professionals everywhere, just won't die.
Show me on the doll where his noodly appendage touched you.
In 25 years (or 50 in England) when the government archives are released, I wonder how many will be readable. This will be a serious problem for historians. I expect it already is a problem but it will get much worse - back in 1979 data formats were still fairly trivial, and paper documents were still pervasive, but complexity has increased immensely since and many documents are electronic only.
What we need are Open Document Standards that the government is required by law to use for all data, whether made public or not, so as to protect the data for the future.
An update to the freedom of information act (in the US) would seem to be one way to achieve this and I believe the GAO has the ability to enforce this and handle the neccesary waiver process in a realistic way.
And while open source doc formats does not imply use of open source software its clear that open source has an important role to play here by providing a means of verification. Its a compelling case where there is a clear societal need for open source software.
Squirrel!
Software only gets changed because our needs, or our perceptions change. If a piece of software was written to perform a task, it can still do that task any number of years from now.
If you wanted to write a document, you could do it in an ancient word processor on one of the earliest home computers. Of course, you would percieve it as slow, and missing some key features, like spell checking, and WYSIWYG editing etc.
Simple things work longer. Keep it simple.
-Z
If 'time_t' goes from 32 to 64 bits, then all software needs recompilation.
I would describe that as "if time_t goes from 32 to 64 bits, then all you need to do is recompile." It's all a matter of how you look at it.
But if there was an interface [...] all we would have to do is change the internals of this class from 32 to 64 bits.
Changing the internals of the object on the other side of the interface isn't the problem that has to be solved. Changing the interface is where the problem comes in.
For example, when the internal representation of file offsets went from 32 to 64 bits in FreeBSD, dumplicating the external interface so old binaries would run was trivial... I was able to provide a compatible system call so you could run old Netscape binaries easily... the problem came when you really needed more than 32 bits in an offset, you *still* had to recompile all the code that operated on values derived from an offset so they would become 64-bit clean. There were two different competing sets of patches for Amanda for a while, one that used floating point for file offsets and one that used 64-bit integers (long or long long depending on the model).
The only time you can get away with just changing the internals is when ALL operations on the object *and* on values derived from calculations on the object (such as a time difference).
Standardised interfaces are what matter, not standards themselves and not clever tools that try to hide the internals as the world changes.
...happens for two reasons in my opinion
... software can only be as advanced as we are, so, many times I look at the advancement of the human brain based on the software we write. And when it comes to advancements in software I very often hear the phrase: "....we've only discovered the tip of the iceberg...", which makes me think: is that telling us somthing about the advancement of us as humans?
1) The way we do business is dynamic. It can have unpredictable changes at any point in time, thus requiring a dynamically *adaptable* infrastructure
2) We do not yet understand software to the point where it can be *adaptable* to the changes which are required in 1).
I've said it in the past, but I'll say it again:
It'll be another few decades before we can write *chameleon* like software that will adapt to the ever changing environment without the need for it to be rewritten from scratch or ditched and replaced by other software
A more important question is: Do we want software that lasts 200 years or are we willing to accept it? When I think of a break though idea in technology (such as building software that will last centuries) and then I think of the big companies which profit dearly from the term *software lifecycle* (which is so short of course), I think of Oil companies and Electical powered cars: until there's $$$$$$$$$$$$$$$$$$ to be made in Oil the later will not suceed (unless the later eventually proves to be more profitable)
It is said but true, that just like the human brain has a sense to invent, (unfortunately) it also has a sense for greed. And usually people will lean towards greed and sometimes *forget* to invent
The phaomnneil pweor of the hmuan mnid. Fcuknig amzanig eh!
We build disposable software, because computers are still disposable.
Not because they can't be built to last, but because they quickly become obsolete.
If Moore's law continues to hold for 40 years, computers will be over a million times more powerful than they are now, the cheapest drive you could buy would hold more than a petabyte, and we'll be saying things like "I remember when a thousand bucks for a terabyte of ram seemed like a good deal, and now I can't even buy a ram stick that small".
Once the breakneck pace of expansion stops (or at least slows to a reasonable rate) then we should look at making software that lasts.
Video compression technology is big business today, but it's probably going to seem like a silly idea in the future.
We don't need buggy whips that last 200 years.
-- less is better.
You know why we can drive the latest vehicle over an old bridge, or fill a new high-tech water bottle from an old well's pump? It's because the way water works has stayed the same - it's a liquid with certain wonderful properties - and the way bridges "interface" with land vehicles has stayed the same.
When we have constantly changing standards, often incompatible with earlier ones, software that works wonderfully with the earlier one will die. This isn't the software's fault any more than it would be the pump manufacturers fault if H2O's density suddenly rose (or viscosity or something).
It's all about the standards.
I [may] disapprove of what you say, but I will defend to the death your right to say it.
Who cares about the hardware, just run it in a virtual machine and be done with it. I have hundreds of game roms, which were never designed to be portable and for which the hardware is becoming increasingly difficult to find. Still, they run great under any number of emulators. I'd be willing to be they'd run just as well 200 years after publication as they do 20 years after publication. If I was to live that long, of course.
Give me Classic Slashdot or give me death!
I used to subscribe to this way of thinking - after all "I'll always have a car payment" and
"As long as I can make the minimum payment, it doesn't matter what my credit card balance is."
This was foolish youth talking, and 'buy now, pay later' immediate gratification marketing that led me for years.
I had a wise aunt and uncle who advised me that I could spend 10% more than I earned, or 10% less. The first way I'd sweat payments for the rest of my life, the second way I'd always have money in my pocket. They were right!
Another great piece of advice from them was "buy a car you can pay off in 3 years. Keep it 6. After the loan is paid off, pay a savings account the same car payment. Then go pay cash for your replacement car. Keep paying yourself, and you'll never need to borrow money for a car loan again." If the next car costs more than the first, keep the first until the savings account has enough to cover the next car.
This REALLY works! I paid cash for my last two cars. I no longer buy what I don't have cash for, and I'm approaching paying off my house, too. Not in the next year or two, but long before 30 years have passed.
A side benefit is that I think much more about whether I really want to spend that extra money on options or gadgets when I'm taking greenbacks out of my wallet!
It is possible to live without debt, even in the US.
But Herr Heisenberg, how does the electron know when I'm looking?
Power users use ed.
Call it wishful thinking, but when I clicked on the article I was under the impression it would comment on the importance of software lasting 200 years on a DIGITAL MEDIUM. I mean, that would be wonderful. Some digital source that won't scratch, break, corrode, or otherwise become corrupted until hundreds of years have passed.
But alas, this article is concerned with software as a whole being built to last. Sure, that's a nice idea and all. But really the importance of long-standing software applications varies from application to application.
I find it much more annoying that the discs I put my software on will fail after a few years!
I wouldn't trust a long Now that can't be cast into an int Now.
+1 Humorous
-kgj
-kgj
The Y2K problem wasn't about "old mainframes from the 60's". It was about a meme that people have, a meme that programmers didn't know, or didn't care that they had, and that you still have. Years are FOUR digits long, not two, as the meme claims. What you meant to say is "old mainframes from the 1960's". The Y2K problem was not a hardware problem, it was/is a psychological problem.
"I'm not impatient. I just hate waiting." - My Dad
The Clock of the Long Now is a clock designed Danny Hillis to last 10,000 years with maintenance using only Bronze Age technology. Ticking will be avoided. The century hand will advance every 100 years, and the cuckoo will come out on the millennium. The first 9 foot tall prototype was built in time for "New Year's Eve 01999" (note extra digit, and the second is under construction now.
One might argue that the clock incorporates firmware, in the sense that there will be relatively complex algorithms to maintain accuracy by comparing different timing signals, and simpler algorithms to decide when to move the century hand, or cuckoo the millennium. It's not a stored-program system though, so it doesn't meet the criteria that the Babbage engines meet. Nevertheless, this is a good example of hardware designed realistically to operate continuously for 10 millennia. For this project Hillis invented a mechanical serial-bit-adder, a mechanical digital logic element, which evidently lacks the "wearing problem" of a standard clock mechanism. The clock knows about leap years and such.
The website has images of the prototypes and the design, but I'm on dialup so I didn't look at them. The Principles Page discusses some of the problems to be overcome. For example, power source - right now Hillis is tending toward a temperature-based power source - and maintaining accuracy, which may be based on a phase locked loop using a mechanical oscillator and solar alignment. There are ways to support the foundation, such as buying Brand's Book, or Eno's tunes
IMHO he might want to use three or four other checks as well. An extension of phase locking can work well with multiple nodes in a network, e.g., the multiple nodes in the human heart rhythm controller. Such networks rapidly converge to a common cycle, and this would provide additional reliability. The NTP network time algorithm is based on multiple sources of the same type, but analogous in concept. Just for fun, it'd be great if the clock also included a display of the 64-bit Unix time, in binary!
This Wired article was written by Danny Hillis about his original idea. The Long Now Website has other interesting links about long term stuff. Hillis has some interesting friends, like Brian Eno who named "The Clock of the Long Now", and Stewart Brand. Other links: Intro to Brand talk, The actual talk. Buy the book, or the Eno CD "January 07003" to support the foundation.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
Many things in society are long-term
Not really true.
Those historical buildings? They've been gutted and rebuilt from the inside out at least once during the past 50 years for the installation central air conditioning and elevators for the handicapped. And they're the exception to the rule. Few commercial buildings go more than 15 years without major renovation and few residential buildings make it more than 30.
Roads? Sure, US Route 1 does still travel approximately the same route but its repaved frequently, expanded and changed frequently, and its been supplanted in its original purpose as the major east-coast north-south route by Interstate 95. And even Route 1 has existed for less than a century. Before automobiles at the begining of the 20th century, there was no need for anything like it. Before automobiles, who could conceive of a multilane asphalt highway that needed to sustain speeds over 500 miles per day? How could yesteryear's engineers possibly plan for it?
The US constitution, the foundation of our law, has seen two major overhauls in the past two centuries: first due to the civil war and again because of the great depression. Even where parts of the text remain the same, their meanings have been drastically altered by the courts. Free speech has become freedom of expression. The right to bear arms somehow doesn't exist at all inside Washington DC except for police. The states have gone from being the primary seats of governance to being almost entirely subsidiary to the federal government. We're living under an almost totally different government than what saw the dawn of the 19th century.
Even the Catholic Church publishes a new catechism each year, a book which defines the religion. You'd think during two millennia they'd figure it out once and for all, yet it continues to evolve and change.
Few things last, either in their original purpose or their original design. They're continuously rebuilt, redesigned and reinvented... Even things like roads, buildings and governments for which our design experience goes back thousands of years.
Our software experience goes back 40 years, if you can call what we did 40 years ago software by any current definition. Why should we build it to last longer than than the roads and buildings, and indeed longer than software in any form has existed?
I'm sorry, but I'm not smart enough to successfully plan ahead two centuries and neither are you.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Rather than nesting all those emulators, wouldn't it have been more straightforward to write a new LEO emulator for the ICL 2900?
If in 50 years we have significant AI and if indeed at that time we see a clear need 200-year software, then let the AIs write it: at least they'll have a better idea of how to do it.
The utility of "200 years" as a software lifetime is unsupported by the article.
On a broader note, who could possibly predict what we'll need in any aspect of life a mere 20 years in the future?
Of course if you did that, there's the danger of noticing that George W. seems to be committing the same sins as George III...
Comment removed based on user account deletion
Maybe we agree after all. That's what I've been saying all along: if interfaces are standardized, the chance of having trouble in changing software would be minimized.
You can't argue though that if we had a persistent object oriented system, our life would be much easier. You said that we don't need such a system, but you did not comment on my example (if 'time_t' was a class).
Furthermore, it is important to realize the difference between 'standard' and 'interface'. A standard only declares 'what', but an interface declares 'what' and 'how' simultaneously. That's why it is not enough to have standards (because data are useless without behaviour).
P.S. you may see that all you have to do is just recompile, and certainly that sounds easy, but in reality, it is translated to millions of dollars lost. With a persistent object oriented system, such loss would be a thing of the past.
...not necessarily self-modifying, but at least self-upgrading. For instance, imagine a system that is part of the "societal infrastructure." This system is running a database... we'll assume for the moment that it's MySQL. MySQL releases a new version. The database (either automatically or at the DBA's request) patches the running binary. There is a short delay of lag while the caches are repopulated, and then the new version is running. Perhaps a "checkChangelog()" function is called, reading a machine-readable changelog to determine if there's any changes to input/output/config files that it needs to know about... no downtime, no kill -HUP, nothing.
I mod down pyramid schemes in sigs.
If time_t was a class, you would still have to define the interface to that class in terms of other classes (date to time, time to date, difference between times, and so on), and pretty soon you realise that time_t is more like one of those interfaces *to* the OS time class, and the object you're reaching for is something like an opaque "struct timespec".
The difference between a standard and an interface is like the difference between a streetmap and a street. There are lots of kinds of standards, good and bad, just as there are lots of kinds of maps... and a good standard defining an interface *does* include 'what' and 'how' and also 'why', where those are relevant to the interface.
With a persistent object oriented system the recompilation is deferred, and the cost when it finally becomes necessary is multiplied many times.
And recompilation can be made as invisible to the user as you like. Take the FreeBSD ports system, for example. It's noisy, yu see compiles going on, but all that chattiness can be hidden behind a GUI and you'll have no idea that it's downloaded new versions of certain packages, recompiled them for the new API, and installed them.
I hink the distinction you're making between are "standard" and an "interface" is superficial, and I think the "persistent object oriented system" is just an implementation detail... and one that's not nearly as capable as you think. Eventually one of the classes exposed in the interface WILL have an incompatible change, so you WILL need to rebuild the code around it anyway, so why not get used to it?
I think there's a good chance my HP11C scientific calculator's software will last for decades/centuries. Closed source, too.
Right now, somewhere, there is a government agency putting important data into long term storage, which was created in Microsoft Word. In a few years that data may be unreadable, not because the medium has deteriorated, but because the software that created it will have evolved or no longer exist.
This is just one example of how proprietary formats are bad for storing important data, long term. This problem was noted years ago when it was discovered that VA tapes, tucked away in underground facilities back in the 60's, could no longer be read because the software that created them is gone.
An ideal data scheme would include information which describes the data being stored along with the data itself. An example is XML. This concept needs to be pushed.
It is more likely that we can solve the problem of proprietary data storage schemes long before we can implement 200 year software.
Proverbs 21:19
Software for hundreds of years is a good idea, but it doesn't go far enough. Reusable software in its current stage is paid of lot of lip service but I still don't think it has reached the point where it needs to be. Perhaps the greatest paradigm shift in the previous few years has been that symantics can be captured without specifying a preferred syntax (intermediate languages and virtual machines). These technologies are good, but they clearly don't yet go far enough (witness the poor support for functional programming languages and the attested "fake" feel of the .NET implementation of C). The point I am trying to make is that the future of software lies in semantics, not languages. Once the semantics are sufficiently rich, any concievable language syntax can be supported.
I have had dreams of software systems being reused thousands of years into the future, including pieces of software that "just work" and were written so long ago that people don't know (or have to know) how they work. This is the point at which technology begins to be indistinguishable from magic.
what about web based software like yahoo's buisness software. its not acually fully replaced. Its just updated.
steve
Or, say some, alleged "rights for [individuals] to bear arms", has been invented from ambiguous original text which literally just seems to imply that states are allowed to have armies, and not directly relate to individuals rights.
I think this closely relates to your points about actual "implementation" of constitution (interpretations) changing over time; there are many ways to read the same passages, in different contexts.
I'm a longtime Linux user; don't touch Windows; but Office is a quality product for those who are willing to put over the money.
Are Word documents data or or not?
For instance, there are things that don't display depending on whether the program is Word or Open Office.
Are unicode text data or not? Display of the text really depends on the character sets. In 200 years time, character sets can change.
You just need to program it well.
Thinking Machines are evil. Human potential is infinite.
There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
Comment removed based on user account deletion
say some, alleged "rights for [individuals] to bear arms", has been invented from ambiguous original text
Well, I'm going to call those folks ignorant. Let me tell you why.
The fellas in the first congress wrote a great deal about their experiences and about the reasoning they used when constructing the bill of rights. There's no need to invent meaning in any of it; all you have to do is read the rest of what they wrote.
The problem is that each of those individuals had a different take on what the second amendment was supposed to mean. At least one saw it as an individual right necessary to keep the government from turning oppressive. To literally make it possible for the people to get out their guns, band together and defend themselves from the U.S. Army if the President turned into a King. Others saw it more as a township's right (where township generally meant a grouping of no more than a few tens of thousands of people) to maintain its own police force instead of having military peacekeepers sent in from afar.
Each of the common interpretations of the second amendment is well supported by the historical documents. Each is also thoroughly refuted by the same.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
f time_t was a class, you would still have to define the interface to that class in terms of other classes (date to time, time to date, difference between times, and so on), and pretty soon you realise that time_t is more like one of those interfaces *to* the OS time class, and the object you're reaching for is something like an opaque "struct timespec".
That's if you design different Date and Time classes. And even if you do, you would just have to change these two classes. You wouldn't have to change applications.
and a good standard defining an interface *does* include 'what' and 'how' and also 'why'
That's what I said. But don't forget that many posters, in the discussion we are commenting, said that as long as data formats are open, there is no problem. But having open data formats (for example Word) is not enough, and this is what I wanted to point out.
With a persistent object oriented system the recompilation is deferred, and the cost when it finally becomes necessary is multiplied many times.
No, it does not. You are wrong in this. The cost of computer power may be increased, but the cost of personnel being involved is tremendously decreased. And it is the human cost that it is the problem today; it is much higher than computing power.
With a deferred compilation system you would also have the benefit of applying the best optimizations possible, according to each specific type of machine that the app runs on. And you would not have to recompile all the apps, just the parts that changed.
And recompilation can be made as invisible to the user as you like.
I am in favor of totally hidden compilation. Just write the code and run it. The system should be responsible for caching the compilation result.
I think the distinction you're making between are "standard" and an "interface" is superficial
and I think the "persistent object oriented system" is just an implementation detail... and one that's not nearly as capable as you think.
Not at all. In such a system, all you have to do is declare members of a class as persistent. You wouldn't have to worry about serialization, since the system would take care of it, knowing what is to be serialized or not.
Most propably you have not understand the benefits of it. With such a system, application development will take the 1/10 of the resources it takes now, and it will effectively unlock the door to distributed computing and paperless office, making the problems we have now a thing of the past. I can give you numerous examples where this applies.
Eventually one of the classes exposed in the interface WILL have an incompatible change, so you WILL need to rebuild the code around it anyway, so why not get used to it?
There will not be such a problem, since classes can be versioned. The system will differentiate between classes of the same name and library by versioning the classes. An application that works with class Foo v1.0 will keep working with that class, and will only use Foo v2.0 if the system is updated or if the application always requests the latest version.
so why not get used to it?
I can not get used to inneffective solutions, since clearly a better solution exists.
That's if you design different Date and Time classes.
No, that's if the requirements for the classes change. As they do... larger disks, faster processors needing more precise clocks, longer-lasting software needing more seconds. Older software will need to adjust to the changes just as much as newer classes.
Anwhere you can get away with versioned classes, you can get away with versioned system calls. That's basically how we got applications like Netscape for FreeBSD 1.x running under FreeBSD 2.x: the new system call had the same name but a different call number, so if you recompiled you got the new interface.
What you're talking about here is defining standards that allow for upgrades. If you have those, it's not nearly as important how you implement them.
But having open data formats (for example Word) is not enough
I'm not sure what you're getting at here. Word isn't an open data format. If anything, Word is a perfect example of the problems your object-oriented persistent data store can cause, because that's pretty close to what a Word document is: a series of serialised COM objects. Because the format is defined in terms of non-human-readable data streams that can only be properly used by the genetic descendents of the software that serialised it, it's opaque and unreadable to everything else... even older versions of the same software.
On the other hand, I can take a 30 year old RUNOFF or NROFF or TEX document, or even documents marked up in formats that aren't any longer available, and still use it.
Trident II (D5) MK6 Guidance System. http://gw5.draper.com:573/business/strategic/strat egic.php
"Dan Bricklin, author of VisiCalc, has written a great new essay identifying a need for software that needs to last for decades or even centuries without replacement."
My first reaction to your comment is, "Would you use VisiCalc today?". (My grin just got bigger)
There's a twist of grim irony in this clique, "Once Software is made, that Software is obsolete."
For example, lets look at what is estimated as 80% or more of all software 'usage' today. Mainly Word Processing, Spread Sheets, Data Bases, Presentations, and Graphics. You would think that this is a type of 'hard' ceiling for this kind of software development.
You'd be wrong, because now is begining to creep into these standard software packages the notion of 'XML', which for the great unwashed is the beginings of 'Data Readability Unification', (DRU). You won't find DRU written anywhere, even today; but XML is growing VERY rapidly.
Which brings me to my drunken thesis, "if something like XML didn't exist 15 years ago, how is software made then going to be able to handle it now?" Well, the solution is now painfully clear. Go forward in time. Get the specs for then. Come back. Write the program. Get paid.
Q.E.D.
No, that's if the requirements for the classes change.
That's what I am talking about.
As they do... larger disks, faster processors needing more precise clocks, longer-lasting software needing more seconds. Older software will need to adjust to the changes just as much as newer classes.
No, it will not. It all time and date operations were encapsulated in a time class, only the time class instance would need to be replaced. Applications would not need to be changed.
Anwhere you can get away with versioned classes, you can get away with versioned system calls. That's basically how we got applications like Netscape for FreeBSD 1.x running under FreeBSD 2.x: the new system call had the same name but a different call number, so if you recompiled you got the new interface.
It's not the same. With plain functions, you loose encapsulation, because data structures are exposed to the programmer...except if the data structures are handles only.
What you're talking about here is defining standards that allow for upgrades. If you have those, it's not nearly as important how you implement them.
Not only that. I also talk about defining the 'how', as well as the 'what'. I am talking about object orientation.
Word isn't an open data format.
It is not, but most bring it up as an example of a format that should be opened.
If anything, Word is a perfect example of the problems your object-oriented persistent data store can cause, because that's pretty close to what a Word document is: a series of serialised COM objects. Because the format is defined in terms of non-human-readable data streams that can only be properly used by the genetic descendents of the software that serialised it, it's opaque and unreadable to everything else... even older versions of the same software
The problem is not my object-oriented persistent data store, the problem is that the COM mechanism is proprietary and you can't run it on Unix. If you could take the class (or classes) that represents a Word document and could use it on Unix, would there be a problem? The answer is no.
The problem is also not that it is in binary format. The problem is that there is no global definition of the class and its representation as code that reads the document.
On the other hand, I can take a 30 year old RUNOFF or NROFF or TEX document, or even documents marked up in formats that aren't any longer available, and still use it.
But you need to write the code to use the document you mention. On the other hand, with my system, all I would do is import the relevant class, even if it was written 30 years ago.
It all time and date operations were encapsulated in a time class, only the time class instance would need to be replaced. Applications would not need to be changed.
...
That's only true if the time class NEVER interacts with any other classes or objects, if it's isolated off in the corner of the world, if there's never any need to deal with time except through the time class. The analogous mechanisms exist in other environments, you know... you can deal with time as an opaque object using well defined routines, but you still have to be able, for example, to take a difference between two times and use it in a calculation and to do that you need to know how big it is, what its granularity is, and so on.
No class is an island.
If you could take the class (or classes) that represents a Word document and could use it on Unix, would there be a problem?
Over decades? If there was no standard defining the class and interfaces? Absolutely... not only is it vanishingly unlikely that I'd be able to find a compatible instance of the class after 30 years, but the chance of the software ecosystem the class depended on remaining stable is vanishingly small.
Plus, you'd be locked into 30 year old programming languages and object models. Think of what that means today: Fortran IV, Simula, Pascal, Pre-Version-6 C (no long data type), no C++, Java, Smalltalk, Modula-2, Standard Lisp,
But you need to write the code to use the document you mention.
I do? Well, for Runoff maybe, but I happen to know that's been done already. Groff handles nroff just fine. TeX is still around, in multiple implementations in multiple languages.
Consider then the model where one makes an XML standard form. Instead of using bits of paper, one has an XML file, suitably filed &c, with part of the crc hidden with the digital signature.
Regardless of the systems in place, the core of the business is not stored in structured program-specific data, but rather forms. One can easily start upgrading the system, or even run several systems, that are none the less capable of using the same forms.
It then would not really matter, for example, if this office used Linux 2060, and that office used OS/4, and some other office is stuck with some legacy operating system such as Longhorn: everyone's talking together in standard defined XML forms, and acting accordingly.
That is, one had basically moved the data to a separate entity to the underlying programs.
OS/2 - because choice is a terrible thing to waste.
Can you really confidently say that we will be using paper 200 years from now, much less paper forms?
Maybe we'll decide it's better to have computers track all the information for us.
Or maybe not.
The point is, designing for the future implies that you can predict that future with some reasonable accuracy.
Predicting what tomorrow will be like isn't hard.
Predict 10 years ahead we can still be fairly confident.
But 200 years?
For all we know, computers might be programming themselves by then.
-- less is better.
Likewise, whatever happens to paper in the next 200 years, does not change the effectiveness of creating a form of authority and request. The point was, that instead of storing data in specific formats, one should start considering a global format for forms, etc, and have programs talk in that way.
The effect of this is that forms can be shunted around the electrical office in the same way that paper forms are now: the form would grow as different things are done to it, and then ultimately stored on different media, such as microfiche, or some other durable medium.
One of the side effects is to reduce the interdependence of programs: the payroll forms, for example could be processed on an OS/2 box, and the accounts sent to a Linux box for further processing. Changing the accounting program would then be easy, since it would be a plug-in system.
OS/2 - because choice is a terrible thing to waste.
The gist is that software development is still in the craft stage -- it has not progressed to the engineering discipline that, say, civil construction reached with the greeks four-thousand years ago....
'He who has to break a thing to find out what it is, has left the path of wisdom.' -- Gandalf to Saruman