C Programming Language Hits a 15-Year Low On The TIOBE Index (businessinsider.com)

Gamoid writes: The venerable C programming language hit a 15-year low on the TIOBE Index, perhaps because more mobile- and web-friendly languages like Swift and Go are starting to eat its lunch. "The C programming language has a score of 11.303%, which is its lowest score ever since we started the TIOBE index back in 2001," writes Paul Jansen, manager of TIOBE Index. With that said, C is still the second most popular programming language in the world, behind only Java. Also worth noting as mentioned by Matt Weinberger via Business Insider, "C doesn't currently have a major corporate sponsor; Oracle makes a lot of money from Java; Apple pushes both Swift and Objective-C for building iPhone apps. But no big tech company is getting on stage and pushing C as the future of development. So C's problems could be marketing as much as anything."

Comments

Rust will replace them all

[Anonymous Coward]

Rust will be the new language everyone uses in 2020.

Re:Rust will replace them all

[Anonymous Coward]

Nah.. It'll be jython servlets running inside a lua hypervisor that is written in javascript.

It's not a popularity contest

[Anonymous Coward]

I don't need a corporate sponsor or a sexy advertising campaign to figure out that if I want something to run on most Linux distributions, as well as the BSDs with minor modifications, C is the obvious choice. Most of the languages being heavily promoted are garbage, that's why companies have to spend money to get anyone to use them. Robust languages don't need a marketing team.

Re:It's not a popularity contest

[Anonymous Coward]

Most of the languages being heavily promoted will be dead 10 years from now. Anything serious and written to stand the test of time is done in C. Everything else is transient.

Re:It's not a popularity contest

[Dog-Cow]

New code is written in Fortran all the time. I guess you don't work in any place doing numerical analysis more complex than Excel. Talk to a Ford engineer some time. I am sure you'd find the same any large auto manufacturer.

problems, lol

[Anonymous Coward]

From TFS, "c's problems": c doesn't have "problems"; programmers who don't use c have problems. Such as their code is slow, overweight, wasteful of resources, and uses only a fraction of the potential available at the low level.

But you keep holding that warm, safe hand. Momma will lead you right to the rubber room. :)

Or, you know. You could actually learn how to write good code at the most powerful level. That's a radical thought.

Re:problems, lol

[ShanghaiBill]

From TFS, "c's problems": c doesn't have "problems"; programmers who don't use c have problems.

That is actually what TIOBE measures. It counts Google searches. C programmers are smart enough that they don't need to search for answers on Google, or they use a better website, such as Stackoverflow. A high TIOBE index can mean a language is popular, or it can mean that language has dumb programmers.

Re:problems, lol

[ShanghaiBill]

C doesn't have a corporate sponsor.

Why is that a bad thing? Is Java better because Oracle owns it?

Re:problems, lol

[Pseudonym]

Flawed logic. C++ doesn't have a corporate sponsor either, and yet it has a native compiler on Windows.

Multiple vendors pay good money to develop compliant C++ compilers for many of the platforms that we use.

The two main challenges I see for C are the competition with C++ and faster hardware.

Most "C compilers" are actually C++ compilers running in a "C mode". The trouble is that most of the corporate sponsors care more about being compliant with the latest C++ standard than being compliant with the latest C standard.

And because C++ is slightly more typesafe (strict aliasing), those optimizers can do more for C++ code than for C. So despite the more complex language, C++ can be marginally faster (~1%).

Probably not even that. In the tiny number of cases where strict aliasing buys you anything at all (which on modern out-of-order hardware it almost never does), it's around the same order of magnitude as the performance that you lose in C++ due to maintaining exception handling information. There's really nothing between C and C++ given the same code these days. In practice, most of the performance gains in C++ come from metaprogramming.

Which gets us to the faster hardware: how often is that performance even needed?

For the vast majority of "embedded" devices that I own, the main performance impact isn't CPU speed, it's battery life. A program which gets its job done as quickly as possible and then puts the CPU into an idle state is far more desirable than one which is perceptually just as responsive but wears down the battery faster.

Re:problems, lol

[serviscope_minor]

Probably not even that. In the tiny number of cases where strict aliasing buys you anything at all (which on modern out-of-order hardware it almost never does), it's around the same order of magnitude as the performance that you lose in C++ due to maintaining exception handling information. There's really nothing between C and C++ given the same code these days. In practice, most of the performance gains in C++ come from metaprogramming.

Actually...

Aliasing information does help. Modern compilers do auto parallelization at both the fine level (SIMD) and the coarser thread level in some cases. Take, for example the following code:

void foo(A* a, B* b)
{
        for(i=0;i

A and B are the same types, there is nothing that stops the base where a=b+1. If A and B are different types, strict aliasing tells us those arrays never overlap, and so the compiler can use wide SIMD instructions in that loop.

If A and B are the same type, in C (and in practice C++ compilers with a nonstandard extension), you can specify "restrict", which informs the compilers that the arrays don't alias and so it can use the wide SIMD instructions. In that case C is a bit better than standard C++, since C++ has no restrict keyword.

Also, when it comes to exceptions, these days it's basically zero cost (I think it is actually zero cost), provided you don't throw. The compilers make throwing expensive to do that. I believe there's some sort of big look up table plus bisection somewhere so it can figure out the throw-position from the program counter, which is quite expensive. Then it jumps from there to the correct bit of unwind code. The practical effect is that there's nothing exception related in the main code except for a throw.

Re:problems, lol

[TheRaven64]

The real problem with C is that WG14 sat on its fingers between 1999 and 2011. C11 gave us:

_Generic - Useful for a few things (mostly tgmath.h, which I've rarely seen used in real code because C's type promotion rules make it very dangerous, but it was quite embarrassing that, for 12 years, the C standard mandated a header that could not be implemented in standard C). Existing compilers have all provided a mechanism for doing the same thing (they had to, or they couldn't implement tgmath.h), but it was rarely used in real code. Oh, and the lack of type promotion in _Generic makes it annoyingly verbose: int won't be silently cast to const int, for example, so if you want to handle both then you need to provide int and const int cases, even though it's always safe to use const int where an int is given as the argument.

_Static_assert - useful, but most people had already implemented a similar macro along the lines of:

#define _Static_assert(x) static int _assert_failed_ ## __COUNTER__ [x ? 1 : -1];

This gives a 1 or -1 element array, depending on whether x is true. If x is true, the array is optimised away, if x is false then you get a compile-time failure. _Static_assert in the compiler gives better error diagnostic, but doesn't actually increase the power of the language.

And then we get on to the big contributions: threads and atomics. The threading APIs were bogged down in politics. Microsoft wanted a thin wrapper over what win32 provided, everyone else a thin wrapper over what pthreads provided. Instead, we got an API based on a small company that no one had ever heard of's library, which contains a clusterfuck of bad design. For example, the timeouts assume that the real-time clock is monotonic. Other threading libraries fixed this in the '90s and provide timeouts expressed relative to a monotonic clock.

The atomics were lifted from a draft version of the C++11 spec (and, amusingly, meant that C11 had to issue errata for things that were fixed in the final version of C++11). They were also not very well thought through. For example, it's completely permitted in C11 to write _Atomic(struct foo) x, for any size of struct foo, but the performance characteristics will be wildly different depending on that size. It's also possible to write _Atomic(double) x, and any operation on x must save and restore the floating point environment (something that no compiler actually does, because hardly anyone fully implements the Fortran-envy parts of even C99).

In contrast, let's look at what WG21 gave us in the same time:

Lambdas. C with the blocks extension (from Apple, supported by clang on all platforms that clang supports now) actually gives us more powerful closures, and even that part of blocks that doesn't require a runtime library (purely downward funargs) would have been a useful addition to C. Closures are really just a little bit of syntactic sugar on a struct with a function pointer as a field, if you ignore the memory management issues (which C++ did, requiring you to use smart pointers if you want them to persist longer than the function in which they're created). C++14 made them even nicer, by allowing auto as a parameter type, so you can use a generic lambda called from within the function to replace small copied and pasted fragments.

Atomics, which were provided by the library and not the language in C++11. Efficient implementations use compiler builtins, but it's entirely possible to implement them with inline assembly (or out-of-line assembly) and they can be implemented entirely in terms of a one-bit lock primitive if required for microcontroller applications, all within the library. They scale down to small targets a lot better than the C versions (which require invasive changes to the compiler if you want to do anything different to conventional implementations).

Threads: Unlike the C11 mess, C++11 threads provide useful high-level abstractions. Threads that can be started fro

So what!

[no-body]

C is great - love it and if somebody shits on it, even more so!

Moronic Subject for an Article

[hoofie]

This really is a moronic article. Programming language choice is not about "popular" or "cool" - it's whatever tool gets the job done. The article also takes a whack at COBOL and Fortran. They might be old but they have been around a long time and are still in heavy use in many areas. The article also ignores things like microcontrollers, arduinos etc whose development tooling invariably uses C. The whole thing reads like it was written by a newly minted graduate.

Re:Moronic Subject for an Article

[lgw]

This really is a moronic article. Programming language choice is not about "popular" or "cool" - it's whatever tool gets the job done.

For a hobby? Sure. Otherwise it's about whatever tool gets the paycheck done. Java sucks today and isn't the best tool for any job, yet it dominates the job market. It was a bad tool 15 years ago, and it will be a bad tool 15 years from now, when it will still dominate the job market. And by then, sadly, $10 computers will run Java easily.

C will always be the kernel guy's tool, and those jobs pay nicely, but there will never be very many of them. C++ has faded (despite being a darn good language with the latest standard, too many burned bridges). C# will go down with the Microsoft ship. Will one of the new fad languages have staying power? Maybe. Likely 1 of them will, if not a current one. But fucking Java just refuses to die.

End of coding

[OrangeTide]

Us C programmers have already written everything there is to write.

Feel free to reinvent the wheel in various toy languages if that is what makes you happy, I soon will retire and won't care.

In other exciting news

[LichtSpektren]

The hammer just passed the screwdriver again on the Household Tools Popularity List. Is it because the hammer has the venerable backing of large companies like Lowe's and Home Depot while the lowly screwdriver is still seen to be a hobbyist's tool unfit for enterprise adoption?

Stay tuned for next month's exciting random statistical variations and the inane commentary from bloggers desperate for clicks!

C programmers don't need to consult the web

[KeithH]

This TIOBE index relies on web queries for each programming language. Frankly, C programmers don't need to ask questions about the language itself since it is so simple.

I'm not questioning the popularity of the various languages but it seems to me that this metric favours the more complex languages.

Finally, in the embedded real-time space, there is still no real substitute for C.