Why do old programming languages continue to be revised?

Question

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?

Answer 1

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.

NOTE

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?"

Answer 2

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.

Answer 3

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

Answer 4

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

Answer 5

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.