46

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?

  • Because there is still demand for them to do so. As long as there are fortran developers who require new features, there will be someone there to fill the gap. It's mostly about the money. – ConditionRacer Nov 01 '12 at 17:49
  • 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 Nov 01 '12 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 Nov 01 '12 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 (http://www.linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php)? Why do they prefer to create a new language and still call it C++? – Giorgio Nov 01 '12 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. –  Nov 01 '12 at 23:40
  • 6
    BECAUSE C NEVER DIES – Caffeinated Nov 02 '12 at 00:03
  • Think of it as of the new languages spawning from the previous versions. C99 is not the same language as, say, ANSI C. And now you can use both, if you want, ANSI C is still available and supported. – SK-logic Nov 02 '12 at 09:17
  • @SK-logic: Yes, but for some languages when a new revision comes out it is implied that it is actually the same language, and that developers are encouraged to abandon the older revision. – Giorgio Nov 02 '12 at 09:29
  • @Giorgio, it is clearly wrong and very bad. Any older language revision must always be available through a complier option (or by using a pragma). – SK-logic Nov 02 '12 at 09:42
  • @SK-logic: Yes, but why call it an older revision of the same language, and not say that there are two languages, one of which is older than the other? Example: I use Java 6 and I am comfortable with it. But I imagine that lots of developers will tell me that Java 7 or 8 is better than Java 6 and that I have no reason to stay with Java 6. Retaining the name is a means to push the adoption of the new language. – Giorgio Nov 02 '12 at 09:45
  • @Giorgio It also informs the user that the language belongs to a certain family of languages. C++11 is a version of C++. The core of the language looks entirely familiar to somebody familiar with older versions. A C++ developer can be fairly certain that the switch to C++11 will be smoother and quicker than the switch to OCAML (assuming no prior experience with either one). – KChaloux Nov 02 '12 at 13:38
  • @Giorgio - Because they are not seperate languages. At the end of the day most changes are all just syntax sugar. C and C++ are two seperate languages, C++ will ACCEPT C code, if an application is compiled with the C++ compiler but written in C that makes it a C++ application. – Ramhound Nov 02 '12 at 13:48
  • "C++11 is a version of C++": I am a C++ developer (been using C++ since it came out in the early 90-ties) and I perceive C++11 as a new language: lambdas, auto (type inference) and a lot of new stuff. I can hardly recognize the code sometimes. I would rather call C++11 a C++ derivative language. I think the decision whether a new name is used is political (keep the community together) rather than technical (how similar the two languages are). – Giorgio Nov 02 '12 at 13:57
  • What should it be called? "C+=2"? – dan04 Nov 10 '12 at 02:13
  • @Adel +1 should be an answer – ZJR Nov 30 '12 at 16:08
  • @Blrfl: Even you can use a compiler switch to enforce an older standard, if you work in a larger team you will be forced to adopt the new standard sooner or later. What I find interesting is that (1) from a practical point of view, moving to a new standard of a language can require an effort comparable to switching to a different language but (2) from a psychological point of view, switching to a new revision of the same language (same language name) seems much more acceptable than switching to a different language (different language name). – Giorgio Dec 05 '12 at 10:06
  • It's funny that you mention TeX. I think TeX is the perfect example of why languages need to keep being updated. The syntax is messy, there are a lot of glitches, and it'll probably never really work well for webpages. – Mark Mar 31 '18 at 15:19

5 Answers5

21

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 – Martin Beckett Nov 01 '12 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 Nov 01 '12 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 Nov 01 '12 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 Nov 01 '12 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 Nov 01 '12 at 23:17
  • "As far as Knuth goes, remember that he is an academic and that TeX is only proven correct, not updated.": Note that packages running on top of TeX (e.g., LaTeX) are being updated all the time and have followed the evolution of typesetting (TeX is not only used for scientific papers) during the last decades. Having a well-defined and stable typesetting engine (TeX) on top of which different evolving packages can be constructed is a design decision which has little to do with TeX's origin in academia. – Giorgio Nov 03 '12 at 12:44
  • @Giorgio it's a joke of sorts related to Knuth's quote: "Beware of bugs in the above code; I have only proved it correct, not tried it." –  Nov 03 '12 at 12:49
  • @World Engineer I understand the joke now. – Giorgio Nov 03 '12 at 13:14
14

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

Giorgio
  • 19,646
  • 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. –  Nov 02 '12 at 00: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 Nov 02 '12 at 07: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 Nov 02 '12 at 07:02
  • 1
    Languages don't die, only the programmers that use them. – Evan Plaice Nov 21 '12 at 03: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. http://racket-lang.org/new-name.html – Giorgio Nov 21 '12 at 20:23
  • @SunAvatar: Consider also this statement "Oracle's position is that Java must evolve -- carefully, of course -- in order to remain competitive." (http://mail.openjdk.java.net/pipermail/lambda-dev/2011-August/003877.html). If a programming language is a product, it is in the interest of the producing company to sell it as much as possible. This can be in conflict with the developers' interest (to have a well-defined, stable programming language, with a clear underlying programming metaphor that remains recognizable through different revisions of the programming language). – Giorgio Jan 09 '13 at 09:05
5

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

TMN
  • 11,363
  • 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. – Avner Shahar-Kashtan Nov 03 '12 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 Nov 05 '12 at 16:05
1

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

Ben
  • 1,594
  • 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? –  Nov 02 '12 at 00: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 Nov 02 '12 at 00: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 Nov 02 '12 at 06: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 Nov 02 '12 at 14:21
  • @mike: What do you mean by "cache features"? – Giorgio Nov 02 '12 at 14:50
  • I meant abstraction features. I didn't mean for the word "feature" to apply to cache. Cache refers to locality of memory. So 2 separate items of "cache control" and "abstraction features". – mike30 Nov 02 '12 at 15:52
  • "You have to modify a language or create a new one.": Again, the point of the question is not whether it is reasonable or not to create a language with features X, Y, and Z (of course it is!). Rather, what are the benefits of revising the same language again and again, sacrificing stability, instead of creating a fresh one. If in ten years logic programming becomes popular, should be produce C-2020 that includes logic programming? I am not speaking about a new language derived from C incorporating logic programming, but the official standard of the C language published in 2020. – Giorgio Nov 02 '12 at 21:20
  • @Giorgio Why do you think that C11 is not a new language? – user253751 May 12 '22 at 12:28
  • @user253751: I admit I am not very familiar with C11 since I haven't worked in C for quite a while. During the time I have been working in C (about 18 years), I had the impression that the language core is pretty stable. Do you mean that C11 is a conceptually different language wrt the previous C revision? – Giorgio Aug 11 '22 at 15:35
  • @Giorgio I mean a new language, not "a conceptually different language". Is British English the same language as American English? Some pedantic people would say no. – user253751 Aug 12 '22 at 06:06
  • @user253751: I do not know: neither of them is my native language. Anyway, of course, every time a new revision of a language is created, you have a new language. However, I think it makes sense to distinguish between minor revisions and substantial changes, even though I admit that it is often difficult to draw a line between the two. So if a new revision does not introduce any substantial changes, I would say that no new language has been created. But, again, I am not a native speaker of English, maybe I am using the wrong words. – Giorgio Aug 14 '22 at 11:02
-2

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.

Martijn Pieters
  • 14,604
DaveM
  • 111