16

If creating an application (that does mostly data processing) that needs to be run now and maybe (maybe not) 10 or 25 years later, what design tips are out there for such applications?

The general rules apply: rely on open source software and proven platforms and failsafe data formats.

The language must be a high-level language for readability reasons (maybe the only option will be re-writing the application in 15 years by someone who has little knowledge of the original code).

I'd go for UNIX(Linux)+Python+YAML/JSON(/CSV/plaintext), any tips for this selection or an alternative toolset? Scheme/lisp has been around for ages and is really hard to screw up the language basics as well, given that everything would be self-contained.

EDIT: please don't forget tips about actual design and code, like 2038 year issue!

Community
  • 1
  • 1
Martin Paljak
  • 4,119
  • 18
  • 20
  • If it's only going to run now, and again in 10 or 25 years, you may want to reconsider its usefulness :-) – paxdiablo Aug 18 '11 at 06:26
  • 1
    While interesting, this question doesn't really have an answer. The question would need to detail the application that is run once every quarter of a century to provide a more narrow scope of discussion. The magnitude of the program determines the how much effort should be but into a everlasting program versus a good specification. – Aleksi Yrttiaho Aug 18 '11 at 06:39
  • 2
    Go c++, they will need next 25y just to make new compiler. – Luka Rahne Aug 18 '11 at 06:45
  • 1
    @ralu: it will also take 25y to understand a template compilation error for any future modifyer :) – amit Aug 18 '11 at 06:48
  • @Aleksi - rest assured that there is a detailed specification as well. I like self-contained specifications, meaning text file based data storage with good enough docs in the headers + well documented source code + formal documentation. I'm still interested in creating a good "reference implementation" paxdiablo - it will be run more often, but for how long, is not known in advance. – Martin Paljak Aug 18 '11 at 06:48
  • @martin - is the question actually "Design tips for a program with a lifespan of 25 years". Now it reads as if the program is run only twice 25 years a part. These are very different, as djna also point out, every program has an unexpectedly long life. 10 - 25 years is not that uncommon even if the program is just stiched together. – Aleksi Yrttiaho Aug 18 '11 at 07:05

4 Answers4

6

Actually, the #1 requirement would be "use a popular language with an International Standards Organization formal spec". This is far more important than any of the other things you mention. ("Open Source"? Please... There are thousands of public domain programs from the 80s and 90s that it would be nigh-impossible to run today.)

For example, if you code rigidly to the C99 or C++98 or C++03 or even C++0x specification, the odds are roughly 99.9999% that a compiler will exist for your platform 10, 20, and 50 years from now that can handle your code with zero changes. This is, arguably, the most useful thing about a formal spec for a popular language.

Coding rigidly to such a spec may not be easy, since many non-trivial programs (e.g. anything with a GUI) cannot be written 100% portably.

But that is still where I would start. Implement as much as you can in 100% standard-compliant code, then isolate the rest (like the GUI) in platform-dependent modules. Minimize the size of the latter, and you will minimize the work your successors have to perform.

Free 3rd-party tools -- whether something like Boost or something like Python -- are great answers to some questions, but not this one.

Nemo
  • 70,042
  • 10
  • 116
  • 153
  • I thought Python 3 had a spec? Anyway, if you stick rigidly to the C99 spec you won't be able to compile it with most compilers. – Chris Lutz Aug 18 '11 at 07:13
  • 1
    @Chris: I did not say "most compilers"; I said "_a_ compiler", which is what you should be looking for here. "Most compilers" will not exist in 25 years. The spec will, and so will something implementing it. Re: Python 3 specification, do you have a reference? Say, an ISO document number? Guido is a great guy, but I am pretty sure he is mortal. I would not place any bets on what would happen to Python in his absence. – Nemo Aug 18 '11 at 07:26
  • My point on C99 was that you'd have trouble compiling it now, though it undoubtedly would work in the future when GCC catches up (soon, I hope). On Python, I feel like I read somewhere that Python 3 was standardized, but I can't remember where, and I don't seem to be able to find any reference for it. (And I don't believe that GvR is mortal. He's actually an omnipotent snake who ages backwards.) – Chris Lutz Aug 18 '11 at 17:34
3

considering that you'll be providing a well documented source code, they could always optimize the code if any new technology comes up that's compatible with your current code. Else, they'l just have to port it themselves.

Bahamut
  • 1,929
  • 8
  • 29
  • 51
3

It would be interesting to know the half-life of a deployed application. My guess is that 10 years is not at all unusual, and the core applications of an enterprise may well be more than 25 years old - there's a heck of a lot of Mainframe/CICS apps out there.

Hence, I'd claim that any serious development has to anticipate that the application will be used for at least 10 years. Large Enterpises may well have a policy of "Evergreening" - that is migrating their applications to later versions of Operating Systems, Databases etc.

It's effectively impossible to second-guess the longevity of any platform, so just select something that's pretty widely adopted and which is in some sense (De facto or formally) a standard.

Your suggested stack is reasonable, Java and Spring or Java EE would be good too.

I would pay attention to the modularity and "openness" of the application. When I say that many apps are more than 10 years old that doesn't mean they fossilised in that time. The apps change both internally and integrate with more and more systems. Those CICS apps now produce data being viewed on mobile devices that were unheard of 20 years ago.

So look at interfaces into your application, choose a layered and modular architecture that allows the internals to evolve and accommodates new integrations.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
djna
  • 54,992
  • 14
  • 74
  • 117
1

Java may be a good language to write it in. java has excellent backwards compatibility, a large standard library that also has good backwards compatibility, and is popular enough that it will most likely be around in 25 years. Even if java falls out of favour, there are enough jvm languages like scala and clojure that one will probably become popular enough to ensure the survival of the jvm and java as a by product.

Python may not be a good choice, as they occasionally break compatibility (python 3 is not compatible with python 2).

sbridges
  • 24,960
  • 4
  • 64
  • 71
  • 1
    If it was 2 years ago, I would have agreed. Many nowdays afraid that oracle will start enforcing legal restrictions on using java, so the future of java for the next 15 years is not very certain :\ – amit Aug 18 '11 at 06:39
  • There was *one* change in Python that broke compatibility in its **20 years** history. I doubt there will be another one in the next 20. – Ferdinand Beyer Aug 18 '11 at 06:41
  • I'm somewhat afraid of Java. What the application does is no rocket science, but decoding Java is sometimes much more difficult than it is to read well written python. Then again, "just buy it from Oracle as a cloud service and let them worry about the continuity, Oracle will be around in 25 years anyway" is not the solution ;) Java is too much tied to commercial environment and is driven by commercial interests. Companies come and go. Hey, Apple does not distribute Java by default any more... – Martin Paljak Aug 18 '11 at 06:57
  • Apple's antics are not to be taken too seriously even though they are currently fashionable. Java will likely be supported one way or another in 25 years time while it might have faded by then to a legacy language. There'll be a lot of 50-80 year old developers that remember the heydey of Java as there are now those that talk about COBOL and APL and whatnot. – Aleksi Yrttiaho Aug 18 '11 at 07:10