Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Often, projects use programming language X, but would use programming language Y if they were started from scratch.

For example, big numerical models may be written entirely in Fortran. Whereas this might be a reasonable choice for the components that need to run fast (alternative would be C or C++), it might be a poor choice for components that either do not need to run fast (such as things dealing with human input or simple visualisations), or where runtime is not the limiting factor (such as I/O, particularly when from the network).

Another example may be when a project is built using a propriety language (such as Matlab; no, FOSS clones are not good enough) and was started at a time when FOSS alternatives were not viable, but ten years later, they are; and it would be beneficial to migrate.

However, due to language inertia, a migration does not happen. Code that works should not be touched, porting code is a time-consuming, expensive process, and programmers are familiar in language X but not necessarily in language Y. Still, in the long term, a migration would likely be beneficial.

Can anything be done to mitigate the problems associated with language inertia? Are there any notable examples of big projects that have successfully overcome this problem? Or is a project bound to stick forever with the initial choices?

share|improve this question

closed as too broad by gnat, GlenH7, Dynamic, MichaelT, Michael Kohne Mar 8 '14 at 17:48

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

the largest problem is most of the "new" languages really aren't better. – Ryathal Dec 7 '12 at 18:11
See here for an extreme example: How mature is FreeBASIC? – user16764 Dec 7 '12 at 18:12
The important question is, how much of a "long term" is there? A rewrite in another language is likely a huge expense. It only makes sense if the rewrite is going to provide a benefit that exceeds that expense. If you can show that the expense is worth it for a particular project, then "what can be done" is to show this to those in charge. If you can't, then you should be questioning why it should be done yourself. – Steven Burnap Dec 7 '12 at 18:13
Code will stay around until the force of a compelling reason for change is enough to overcome whatever inertia prevents it. That holds equally true for 40-year-old FORTRAN and the code you wrote last week. – Blrfl Dec 7 '12 at 18:24

To my experience, migrating a working product from language A to language B will only happen if there are hard, fact-proven, technical or legal reasons which will make further development in language A impossible. Almost no company will invest in a language transition for any other reasons.

Some real-world examples I have seen so far:

  • a key component of the product won't be further developed and there is no adequate replacement in language A

  • the COBOL based system runs on hardware which is so old that you cannot buy any spare parts for it, and the migration to a modern COBOL dialect on modern hardware does not seem to be cheaper than a migration to a more modern language

  • licensing issues with core components

  • the old system was based on 16-bit-Windows-components where no 32 bit pendant is available any more, and you need to support 64 bit Windows

  • the language itself (the compiler/interpreter) is not supported any more, neither by the creator nor by any third party vendor, or at least not within your target environment

share|improve this answer

Well, large projects are ported from an old language to a new one (and from old platforms/technologies/frameworks to new ones) every day. At least a couple of companies I worked in underwent such passage (usually from FORTRAN to C++).

There are even a few cases of open source programs ported from a language to another. The first version of GNU Arch by Tom Lord (the archetypical predecessor of GIT and similar DRCS tools) was written as a bunch of Bash scripts and was later ported to C.

In most cases, these portings are performed using special translation tools (thirdy-party or custom-made). Usually, the resulting code need some (or a lot) of manual tweaking but very often it is possible to perform such portings.

Despite this, there are at least a couple of good reasons for not performing such portings:

  1. Most of times, porting code from a language/platform/framework/technology to a new one just does not make any sense. The end user buy a solution (a working program) not a cool choice of development tools and technologies. As a consequence, the software company focus on selling working products and anything else.

  2. Porting code is the easy part. Most of times, you have to port a lot of other details (because the new environment does not support the old ones any more). Devil thrives in details and these details can byte you very painfully.

So, usually a project (small, medium or larger, it deos not matter) will be ported to a new "something" only if the old one cannot be used anymore. A typical example is the passage from 16 bit to 32 bit architectures.

Of course, there are a couple of tools/ways to ease the passage from an old technology to a new one:

  1. Good, reliable translation tools.

  2. Proven porting methodologies.

share|improve this answer

... it always depends on what the 'long term' really is. Server-based code and runtimes that fill the specific needs (given businesses and people) will never be migrated. That chunk of code may have 30-odd years of investment, bugfixes and functionality built into it.

Where most bang for the buck in migrating is seen is in changing user interfaces - a Visual Basic app cannot be 'ported' to an iPhone application, etc., etc. In assessing migrations (or even new architectures), keep a careful eye on that MVC type separation so that it may one day become possible (or simpler) to put a new UI on top of a successful application.

Other example: while we've moved from greenscreens to web architectures, there is still a lot of PL/SQL code driving functionality in Oracle data-driven applications. In more than a few cases, I can't see any PL/SQL being 'rewritten' or ported to anything else, as long as the Oracle database is still around...

share|improve this answer

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