Recently i have looked at the "timeline" of Programming Languages and while a lot has changed in the past 5-10 years, there are a lot of languages that have pretty much "stayed" the same in their niche/use.

For example, let's take C language. We don't really ever see much languages being developed (correct me if i'm wrong) to try to Unseat C. However, there are a lot of languages that try to do similar things (look at all the SQL/No-SQL languages) Scripting Languages, etc...

Is there a reason for this trend?

Or is it just because C was designed very well ? and there isn't really any need for new once?

closed as not constructive by Joel Etherton, Blrfl, Caleb, Martin York, Jalayn Oct 4 '12 at 6:34

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I think 'unseat' is a rather strong term. C is and was used for many things - system-level code, operating systems, general software, networking, and even stuff like web code. C++ was designed as a better C, Java and C# were created to replace C++, and some stuff that used to be done in C (like web stuff, some software dev) has moved into other languages. – wkl Oct 3 '12 at 20:25
  • Unseat is a very strong term. It isn't a competition. – Blrfl Oct 3 '12 at 21:10
  • 4
    @Blrfl: Tell that to the language designers :) – Steven Evers Oct 3 '12 at 21:20
  • @SnOrfus: Only take language designers seriously if they have facial hair (exception to the rule Ada). – Martin York Oct 3 '12 at 23:29
  • "Unseating" an established language is practically impossible. Nobody has yet managed to unseat Fortran... – comingstorm Oct 4 '12 at 17:47

There are lots of languages trying to replace C

First there was C++, and then Java and C# trying to replace that.
Recently Go is trying to replace C directly.

But there is a lot of legacy code and much more legacy experience in C so you can't do things too different and hope to be an instant sucess

  • 1
    The reason that the languages you mention (with the possible exception of C++) have not unseated C as the primary language of choice for maximum interoperability is that every language can integrate with C code more or less. Try using a Java library in Haskell or a Prolog library in Erlang. Pretty tough. Now try and use a C library in any of those languages. It is completely possible and pretty easy to do in most circumstances. Plus there is a C compiler for just about every device in existence where the same is not necessarily true of other languages. – Cromulent Oct 3 '12 at 20:40
  • I don't think it's warranted to say C++, Java, C#, or anything else replaced C. They replaced it for certain applications in certain environments. For example, in the GNU/Linux world and in embedded, C is still king. And I don't see many new languages trying to compete there. – user7043 Oct 3 '12 at 20:47
  • @delnan - I said they tried. Nothing has replaced C in it's core markets server/OS/embedded. – Martin Beckett Oct 3 '12 at 21:40
  • 1
    Don't think I agree that any tried to replace C. I think that C++ was trying to make programming easier than C by using other paradigms. Java and C# are really attempts to replace C++ (not C). – Martin York Oct 3 '12 at 23:27
  • I’d say that all those languages have pretty much succeeded. C still has a very important niche but few people would still use it for general-purpose application programming (except the Gnome people, and even there it’s waning). C certainly has the monopoly for systems programming but no longer for much else. – Konrad Rudolph Oct 4 '12 at 14:38

I would not expect any dramatic changes. Only minor improvements might be seen toward the problems that frameworks try to solve gracefully with less line of code.

Thus, there are more and more abstractions and tools to automate process of template-ing certain code to achieve CRUD code generation. In another word, tools/frameworks are created to sustain fast phase development methodologies and productivity demands. However, fundamental concepts of languages (loops, exception handling, etc.) are remaining almost un-changed.

For example, take T4-code generation in C#. It is another powerful add-on to deal with routine code generation like it is done with text generation in this example code - Code Generation and T4 Text Templates.


It would be very hard to "unseat" C: it combines the performance of an assembly language with the expressive power of an assembly language, while offering a decent degree of portability. If you desire raw execution speed, would prefer not to code in assembly, and do not care for additional abstraction layers, C perfectly fits the bill. Some development has been going on on the standards side of C, bit it was mostly for minor features.

In contrast, C++ has evolved a lot, adding lambdas and significantly improving the template mechanism. However, the goal was to make C++ more suitable for higher-level tasks, not to improve its speed - it can be as fast as C already, because it's very close to being a proper super set of C (there are semantic incompatibilities between the two languages).

  • Sometimes, C++ is even faster than C. For example, std::sort beats the crap out of qsort. – fredoverflow Oct 4 '12 at 4:58
  • @FredOverflow In all fairness, that's the library, not the language. You can get the same speed in C, but you'd need to do a lot more coding. – dasblinkenlight Oct 4 '12 at 10:25
  • @dasblinkenlight No, you can’t – not at the same high level of abstraction. Consequently, that’s a property of the language, because it enables you to write such code. – Konrad Rudolph Oct 4 '12 at 14:39
  • @KonradRudolph Of course you can - take the template sort, manually translate it for your particular type, and off you go. I agree that the level of abstraction will not be the same, but the speed will be there. Contrast this to Java, where copying the same algorithm will not necessarily get you the same speed because you have less control over the memory footprint of your data. – dasblinkenlight Oct 4 '12 at 14:44

As languages are used, it will become clear that certain things are missing from the language, and such things will be added. In hindsight, it will be clear that some things could have been done better, but language designers are generally very hesitant to break backwards compatibility and thus large languages are likely to stay with these details (think C++).

Every so often, people will look at these languages, groan at all the flaws that they find, and decide they can definitely do better from scratch. Every once in a while, such a language will get a larger audience and perhaps replace an existing language as "the hip thing". (The old language will still be used in legacy code, of course.)

These changes are going to be slow; language adoption is hard, companies don't want to risk using an untested platform, but changes have happened up to now, and there's no reason to believe they won't continue to happen in the future.