Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I want to know what are the programming languages that have longevity? I mean, code that written today be able to run for next 20 years or so?

share|improve this question

closed as not a real question by Yannis Rizos, Falcon, Walter, Tom Squires, Otávio Décio Dec 4 '11 at 13:41

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
Considering that people are still using COBOL, and that MAME projects are emulating obscure arcade chipsets decades later... all of the languages, if you include emulated environments. –  Patrick Hughes Dec 4 '11 at 8:13
1  
There is Programming Languages and there is software that provides these Programming languages. Just look what language is used to build these language instantiations. Simple answer: C and C++. –  rubber boots Dec 4 '11 at 10:45
    
catb.org/~esr/intercal –  BЈовић Dec 4 '11 at 11:37
    
Lisp dialects keep popping up. Also, given the way it's structured it would be easy to compile one dialect into another. –  Annan Dec 4 '11 at 12:30
2  
Pseudocode is still the same as it used to be in the 50s. –  SK-logic Dec 4 '11 at 12:35

9 Answers 9

Nobody can see into the future. Current mainstream languages are a good bet though. When it comes to aging of a software product it is usually the environment that makes it impossible to run the software not the absence of a compiler for the programming language. The environment can include things like libraries or databases used, the target platform in terms of operating systems and hardware.

I would say that you will be able to run a current Java/C++ program even 20 years down the road. Depending on what it does it might not be useful anymore, not because of technological reasons, but because the original use case changed or is no longer relevant. According to this paper only 35% of changes during the maintenance phase are related fixing bugs or adapting to a changed environment. 65% on the other hand are necessary because the requirements changed.

share|improve this answer

Well, depends on what do you mean by "outdated"? COBOL has been used for 50 years and still kicking.

Personally, I've been working on a C++ program that contains comments dated 1991, and I don't see why it couldn't be used for another 20 years. As much as C++ is bashed, it (as well as C, Fortran, COBOL, and SQL, for example) is officially ISO/IEC-standardized. The standardization, together with a broad user base, can be seen as some sort of indication that the language is seriously persistent.

Unlike mechanical or electronic devices, software doesn't wear out. The continuous updating hell of PC and mobile systems may give a distorted impression of how things work in e.g. embedded or scientific systems. If it works now, it works as long as the hardware works!

share|improve this answer

Basically, there is nothing wrong with running things on a 20 year old computer. Bits don't rot, and it is not unseen that old installations of software on NT or even DOS hide in a corner of an organization. The typical reason for these not being migrated to a virtual environment, is because they frequently need a hardware dongle that is not supported by the virtual host.

But I think you are essentially asking "How can I write programs that will run for new users in 20 years or so?"

Back in the Windows 95 days Microsoft was very keen on having old DOS software run perfectly because they needed people to use Windows 95 instead of any of their competitors. Back in Windows 2000+XP days Microsoft was very keen on having old DOS+Win95 software run perfectly because they wanted people to switch to 2000+XP. Today this is much less the case. Will Silverlight be supported in 10 or 20 years? ActiveX? C#?

Will the most popular platform even be Windows? Or Linux? Or OS X?

The current best bet for what you need is Java, as there has been very large focus on binary compatibility. New versions of Java run old programs unchanged. Java then has other issues which may or may not be relevant to you, depending on what is most important to you.

share|improve this answer

All languages that ever compiled to machine code, for a start. x86 won't be ditching it's instruction set for a long time to come, if ever. That stretch of time is more lucky about the changes in bit rating. 16-bit code written in 1991 won't run on a modern 64bit OS, so it doesn't matter what language you use, unless it's interpreted or managed, of course. However, I believe that 16bit had a much longer run.

However, in 20 years, the software industry and, hell, even every industry changes so much, nobody would ever want to.

share|improve this answer
3  
even the bitness of a software doesn't really matter; most computer nowadays are powerful enough to run 16-bit program better than a real 16-bit machine in those days using an emulator –  Lie Ryan Dec 4 '11 at 10:41

Longevity also includes the environment your program runs in. If your program needs to interface with its environment (e.g. the operating system) on more than a STDIN/STDOUT level, then that's more important than the language it was written in.

share|improve this answer

I'm going to interpret this question from a pragmatic point of view (since theoretically, it will probably be possible to run any language with a lot of perseverance and creation of appropriate emulators).

Longevity for a programming platform requires the following things:

  • A large installed base of users - languages exist because they are being used to deliver value in some way. The size and significance of the user base will tend to support the continuation of a language / platform
  • Maintenance of the language and libraries - somebody needs to invest in updating the language and libraries or else it will become outdated / incompatible with the systems it is required to run on. This seems to require either strong corporate backing or an effective open source community model.
  • Cross-platform portability - even if a language doesn't change much, the systems it has to run on certainly will. A language that is tied to a particular platform will probably not stand the test of time.
  • Backwards compatibility - if people want to run their systems on a language / platform for many years, it is extremely important that there is a string commitment to backwards compatibility. Without this, staying on the platform will be expensive and risky (especially for large corporates etc.)
  • Innovation and new development - platforms need a certain amount of innovation order to stay relevant and compelling vs. the alternatives and as the world changes. People need to have good reasons to choose the platform for new development projects

On balance, I think the language / platform with currently has the strongest position with respect to these attributes is the Java / JVM ecosystem. Java has the largest user base (with particular strength in large corporates and banks that tend to keep the same systems running for many years), it is very actively maintained (both by Oracle/IBM/Google and the open source community), it is designed to be fully cross-platform, and there is a strong history of backwards compatibility. From the innovation perspective, you have new JVM languages like Clojure and Scala that are making the JVM a compelling platform for new development.

share|improve this answer

I see this as, can i trust a platform vender and the standard which the platform and language support. If you can trust both vender and standard body will keep the technology relavent for that long, that should be a positive indecation. According to me standards like ISO can be trusted for that long. So Unix/C++ type combinations are great for long term.

share|improve this answer

In addition to what was said, there's one huge phenomenon: Legacy code.

Long story short, people don't switch to newer languages (possibly better suited for a given project) because transferring an old project, along with all its dependencies, documentation etc (not to mention retraining the staff) to a new language/platform/whatever would simply be too costly.

share|improve this answer

Every language evolves in certain manner, but same time every change in the language is normally done with effort to preserve backward compatibility, that is why the simpler is your program and the less cut-edge features you are using there the more are chances that your program will also smoothly compile and run in 20-25 years. Provided the language is still alive...

There are several "hacks" to answer your question in a probably different manner than just mentioning COBOL to a most vivid example of a "frozen" language. Here are some:

  1. Languages used for learning remain a sort of "children among languages" for ages. Look at Logo, I programmed it when I was 12, now I am 32 and the language is still the same. If you are fine with turtle graphics in your program, use Logo -- it will hardly change not to support it anymore.

  2. Language with large existing code corpus usually (but not always) tend to be slower as regards their evolution and the changes are usually not so "breaking", at least they don't break the backward compatibility. So, if you stick to C, for example, you should be on a safe side too. Just stay at ANSI C, the most common denominator of the language.

  3. The closer your language to the machine code level the less are chances that it will be modified/updated in the way the something is deprecated and not compatible anymore. If you consider Assembler being a language (you never mention if you want only the high-level languages), then write your code in x86 Assembler -- even if the CPUs in 20 years will use the bioorganic base and ternary system, the will be enough virtual machines available to run your code smoothly, I am sure.

  4. The best way to keep your language "young" is to develop your own compiler and virtual machine to execute your code. Taking into account the third point here, just implement your own compiler and VM and write your code in YOUR language. I am pretty sure, unless your project is extremely successful nobody will ever dare change your private project, so you are always on the safe side programming in this language.

share|improve this answer
    
COBOL is not frozen. –  user1249 Dec 7 '11 at 18:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.