This question is not, "Why do people still use old programming languages?" I understand that quite well. In fact the two programming languages I know best are C and Scheme, both of which date back to the 70s.

Recently I was reading about the changes in C99 and C11 versus C89 (which seems to still be the most-used version of C in practice and the version I learned from K&R). Looking around, it seems like every programming language in heavy use gets a new specification at least once per decade or so. Even Fortran is still getting new revisions, despite the fact that most people using it are still using FORTRAN 77.

Contrast this with the approach of, say, the typesetting system TeX. In 1989, with the release of TeX 3.0, Donald Knuth declared that TeX was feature-complete and future releases would contain only bug fixes. Even beyond this, he has stated that upon his death, "all remaining bugs will become features" and absolutely no further updates will be made. Others are free to fork TeX and have done so, but the resulting systems are renamed to indicate that they are different from the official TeX. This is not because Knuth thinks TeX is perfect, but because he understands the value of a stable, predictable system that will do the same thing in fifty years that it does now.

Why do most programming language designers not follow the same principle? Of course, when a language is relatively new, it makes sense that it will go through a period of rapid change before settling down. And no one can really object to minor changes that don't do much more than codify existing pseudo-standards or correct unintended readings. But when a language still seems to need improvement after ten or twenty years, why not just fork it or start over, rather than try to change what is already in use? If some people really want to do object-oriented programming in Fortran, why not create "Objective Fortran" for that purpose, and leave Fortran itself alone?

I suppose one could say that, regardless of future revisions, C89 is already a standard and nothing stops people from continuing to use it. This is sort of true, but connotations do have consequences. GCC will, in pedantic mode, warn about syntax that is either deprecated or has a subtly different meaning in C99, which means C89 programmers can't just totally ignore the new standard. So there must be some benefit in C99 that is sufficient to impose this overhead on everyone who uses the language.

This is a real question, not an invitation to argue. Obviously I do have an opinion on this, but at the moment I'm just trying to understand why this isn't just how things are done already. I suppose the question is:

What are the (real or perceived) advantages of updating a language standard, as opposed to creating a new language based on the old?

  • 2
    Many compilers can be invoked with switches that will enforce older standards (e.g., GCC's --std=x switch), so it's not as if creating newer standards results in tools that destabilizes older code.
    – Blrfl
    Commented Nov 1, 2012 at 18:05
  • 2
    How do you define "a new language based on the old"? I would argue Fortran 90 is a "new language" based on the old F77. It completely changed how you program -- fixed vs free source, dynamic vs static memory, etc.. You could also argue that Fortran 2003 is a "new language" based on F90 -- it added object oriented programming while retaining compatibility with F90. Sounds like the relationship between C++ and C.
    – tpg2114
    Commented Nov 1, 2012 at 21:08
  • 1
    I think this question is very important and I do not understand why some want to close it. It is a very interesting phenomenon that probably has some explanation. A few (20?) years ago I was reading about new features of Fortran and asked myself: if Fortran programmers need these features, why don't they simply switch to C? Recently I had similar consideration regarding C++: if C++ developers want to use lambdas, why don't the switch to, say, OCaml (linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php)? Why do they prefer to create a new language and still call it C++?
    – Giorgio
    Commented Nov 1, 2012 at 22:37
  • 3
    @tpg2114 The difference between (FORTRAN 77 : Fortran 90) and (C : C++) is that Fortran 90 is considered to have superseded FORTRAN 77, to the point where people are told, "If you want to learn Fortran, learn Fortran 2003 or at least 90, because that's the standard now." No one would say something like, "If you want to learn C, learn C++ because that's the new standard," because they are presented as two different languages. As I said, connotations do have consequences.
    – user71599
    Commented Nov 1, 2012 at 23:40
  • 6
    BECAUSE C NEVER DIES Commented Nov 2, 2012 at 0:03

5 Answers 5


I think the motivation for language designers to revise existing languages is to introduce innovation while ensuring that their target developer community stays together and adopts the new language: moving an existing community to a new revision of an existing language is more effective than creating a new community around a new language. Of course, this forces some developers to adopt the new standard even if they were fine with the old one: in a community you sometimes have to impose certain decisions on a minority if you want to keep the community together.

Also, consider that a general-purpose language tries to serve as many programmers as possible, and often it is applied in new areas it wasn't designed for. So instead of aiming for simplicity and stability of design, the community can choose to incorporate new ideas (even from other languages) as the language moves to new application areas. In such a scenario, you cannot expect to get it right at the first attempt.

This means that languages can undergo deep change over the years and the latest revision may look very different from the first one. The name of the language is not kept for technical reasons, but because the community of developers agrees to use an old name for a new language. So the name of the programming language identifies the community of its users rather than the language itself.

IMO the motivation why many developers find this acceptable (or even desirable) is that a gradual transition to a slightly different language is easier and less confusing than a jump into a completely new language that would take them more time and effort to master. Consider that there are a number of developers that have one or two favourite languages and are not very keen on learning new (radically different) languages. And even for the ones who do like learning new stuff, learning a new programming language is always a hard and time consuming activity.

Also, it can be preferable to be part of a large community and rich ecosystem than of a very small community using a lesser known language. So, when the community decides to move on, many members decide to follow to avoid isolation.

As a side comment, I think that the argument of allowing evolution while maintaining compatibility with legacy code is rather weak: Java can call C code, Scala can easily integrate with Java code, C# can integrate with C++. There are many examples that show that you can easily interface with legacy code written in another language without the need of source code compatibility.


From some answers and comments I seem to understand that some readers have interpreted the question as "Why do programming languages need to evolve."

I think this is not the main point of the question, since it is obvious that programming languages need to evolve and why (new requirements, new ideas). The question is rather "Why does this evolution have to happen inside a programming language instead of spawning many new languages?"

  • This answer makes the most sense to me of any I've seen here: updating a language allows you to inherit (at least some of) the existing community, libraries, etc. I recall reading that Lisp's biggest problem is the large number of slightly incompatible dialects that make it hard to maintain a community; updating an existing language could be a way to avoid fragmenting other communities in the same way.
    – user71599
    Commented Nov 2, 2012 at 0:46
  • @SunAvatar: As far as i know Lisp has several dialects but some are more successful than others (Common Lisp, Scheme, Racket, Clojure). Any time you start a new language you take the risk that only a very small community will gather around it. In the Lisp community this seems common practice: if someone has a new idea, they branch and see what happens. For the creators of other languages, losing the community is not an option.
    – Giorgio
    Commented Nov 2, 2012 at 7:01
  • @SunAvatar: I do not see inheriting existing libraries as a strong argument. You do not need source code compatibility for that. See e.g. how Clojure and Scala can use Java code.
    – Giorgio
    Commented Nov 2, 2012 at 7:02
  • 1
    Languages don't die, only the programmers that use them. Commented Nov 21, 2012 at 3:09
  • @SunAvatar: There are also communities that try to follow a different policy: a name identifies a language, and if a part of the community creates a dialect that diverges too much, they use a fresh name to avoid confusion. See e.g. racket-lang.org/new-name.html
    – Giorgio
    Commented Nov 21, 2012 at 20:23

Backward Compatibility is your answer. A given language, particularly a widely used one like C may have code that is in operation, unaltered, for decades. If there needs to be maintenance, it helps to have compilers that can still target that kind of a platform whilst running on modern systems for development work. Standardizations and language version updates help keep programming practices current whilst providing a sense of familiarity for the veteran programmers who may be resistant to learning a whole "new" language.

Keep in mind that many of the updated languages are less updated so much as "have new shiny bits bolted on". The beasts of yore often still lurk within.

As far as Knuth goes, remember that he is an academic and that TeX is only proven correct, not updated.

  • 14
    The problem domain of Tex = format scientific paper text, hasn't changed much. The domain of programming languages = find new uses for new computers, is rather more expansive. It's the same reason that Latin doesn't add quite so many new words as English Commented Nov 1, 2012 at 20:56
  • I do not think that backward compatibility is a valid reason: Scala can be easily integrated with existing Java code but it is not a super-set of Java. So I think in general it is not necessary for a new language to be compatible with an old one at the level of source code. It is sufficient to have a well-defined mechanism for calling legacy code from the new code.
    – Giorgio
    Commented Nov 1, 2012 at 21:06
  • @Martin Beckett: "The problem domain of Tex = format scientific paper text, hasn't changed much.": I think you are missing the point of the question. The OP is not asking whether there should be innovation in programming languages (nobody can deny that innovation is necessary) but why old languages are revised instead of creating new ones.
    – Giorgio
    Commented Nov 1, 2012 at 22:41
  • Systems are built on investments of time, money, and expertise (experience gained in a particular language). New efforts cost significnatly more than maintenance efforts (in all three categories). Without improvements to the language and platform in general, the cost of maintenance goes up, and then the cost of a new system is more attractive and the genuine rehosting that COBOL app onto an entirely different platform for the eighth time in its life may not seem like such a great deal anymore.
    – JustinC
    Commented Nov 1, 2012 at 23:09
  • If it wasn't for the updated standards of the COBOL language and the COBOL tool implementers adding their own unique features along the way, that improved the language, and improved the ability to operate on wider, mainstream, modern platforms; the app wouldn't have survived 60 years. While relative costs certainly rose later in it's life, due to an increasing scarcity of expertise, the effort on a whole was pennies on the dollar compared to a regular rewrite when the language of the moment emerged.
    – JustinC
    Commented Nov 1, 2012 at 23:17

I think the obvious answer is that progress is still being made in language design and system architecture, and enough people care about the older languages that they want to take advantage of newer techniques (multiple cores, better threading or memory models) that they get bolted on or baked into the language standard. It also helps to have "one true way" to do things (e.g., XML parsing, DB access) that you can count on to be there no matter what compiler or platform you're on, as opposed to depending on some third-party library which may or may not be installed (and may or may not be the version you require, etc).

  • So if "enough people care about the older languages" is the reason, would you say your answer can be rephrased as "sentimental attachment to existing languages"? I'm not saying that pejoratively, just trying to understand your answer. Commented Nov 3, 2012 at 12:38
  • No, I meant the languages are still in active use, and they're used by people who want to take advantage of the latest techniques. I don't think anyone's going to be adding multithreading support to ALGOL because (AFAIK) it's not being actively used. FORTRAN and COBOL, though, are still used to develop new systems, so their language specs are updated periodically to incorporate new techniques and technologies.
    – TMN
    Commented Nov 5, 2012 at 16:05

The fundamental concepts or goals a general purpose language is built around do not lose relevance; however minor changes in work environment or hardware demand that updates or small features be added to a language.

The way algorithms are expressed in a language will not change, even though it may need cleaner support for 64 bit types, or more standard regular expression support, or more robust support for new types of file systems.

There are a few cases where 'new' features are being added to existing languages, but in many cases those changes amount to simplifications of things people were already doing the hard way. (See C++ using high order functions instead of function pointers and functors.)

  • 1
    The changes you describing in the second paragraph are pretty unobjectionable (by which I mean not just that I don't object, but that no one can seriously object). As for lambdas, I can't comment on their usefulness in C++, but why bother adding them if not to change the way algorithms are expressed?
    – user71599
    Commented Nov 2, 2012 at 0:17
  • Oh, they are incredibly useful. Don't get me wrong. They're the most important addition in C++ (IMO). I think I was not clear about what I meant there. One usually chooses C++ to have direct access to memory, deterministic performance, and high optimization potential. That doesn't change with the recent additions. We simplify many of the other programming tasks around why you chose C++, but C++ is still valid and useful for the same reasons. Scheme is updated with regularity, but the code-as-data and lispy-ness doesn't change, so you choose scheme for the same reasons today as 20 years ago.
    – Ben
    Commented Nov 2, 2012 at 0:41
  • "As for lambdas, I can't comment on their usefulness in C++, but why bother adding them if not to change the way algorithms are expressed?": I go even further: why adding them to C++ instead of switching to a language that has had them since the beginning?
    – Giorgio
    Commented Nov 2, 2012 at 6:58
  • 2
    @Giorgio To have control of the cache and abstraction features in the language. If no existing language provides both, then you can't switch languages without sacrificing one. You have to modify a language or create a new one.
    – mike30
    Commented Nov 2, 2012 at 14:21
  • @mike: What do you mean by "cache features"?
    – Giorgio
    Commented Nov 2, 2012 at 14:50

This is a bit like a consideration of spoken language.

In the past there where words that weren't used as often as they are now (or used for a different meaning).

eg. nice : in (very old) english has the almost inverse meaning to that which we use today, especialy when used to describe someones character.

Bad : not very long ago bad only had a single meaning, now it can mean something that is "super amazing" (it is used in a fesicous way (i've probably miss spelt fesicous)!

another new development is mobile phone 'Text speak' for written languages.

I don't personally see why a programming language isn't going to develop in a similar way, words and funcions have specified meanings / actions, and it is required to change so as to incorporate new ideas, new methodologies.

I know people who speak many different languages, and they often suggest that after the 3rd or 4th it becomes easier to learn a new one.

I don't know if there are programmers who have a similar experience, I wouldn't be surprised if there were.

I know that I feel happies programming in JAVA (much as I feel happies speaking in english) This doesn't mean I can't communicate in 'american english' or 'australian english' although there are some 'gotchas' to watch out for. Much like going from Java to PHP to Perl, the constructs are similar, but there are little gotchas to catch me out and make me bash my head against the wall.

This is different to moving from English to French, or Java to SAS. these are so different it takes quite a while to become proficient at them.

Anyway that is my take on this.

  • I think you're thinking of "facetious".
    – uliwitness
    Commented Dec 20, 2016 at 13:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.