Design tips for a program to be run in 25 years [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

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 de开发者_运维知识库sign 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!

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.

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.

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.

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).