Become a fan of Slashdot on Facebook


Forgot your password?
Programming Stats

Is The C Programming Language Declining In Popularity? ( 286

An anonymous reader writes: Java overtook C as the most popular language in mid-2015 on the TIOBE Programming Community index. But now over the last 13 months, they show C's popularity consistently dropping more and more. C's score had hovered between 15% and 20% for over 15 years but as 2016 ended, the language's popularity is now down to 8.7%. "There is no clear way back to the top," reports the site, asking what happened to C? "It is not a language that you think of while writing programs for popular fields such as mobile apps or websites, it is not evolving that much and there is no big company promoting the language."

But the Insights blog at counters that TIOBE "has hammered on C for quite some time. Earlier this year, it again emphasized how C is 'hardly suitable for the booming fields of web and mobile app development.' That being said, job postings on Dice (as well as rankings compiled by other organizations) suggest there's still widespread demand for C, which can be used in everything from operating systems to data-intensive applications, and serves many programmers well as an intermediate language."

i-programmer suggests this could just be an artifact of the way TIOBE calculates language popularity (by totaling search engine queries). Noting that Assembly language rose into TIOBE's top 10 this year, their editor wrote, "Perhaps it is something to do with the poor state of assembly language documentation that spurs on increasingly desperate searches for more information." Maybe C programmers are just referring to their K&R book instead of searching for solutions online?
This discussion has been archived. No new comments can be posted.

Is The C Programming Language Declining In Popularity?

Comments Filter:
  • by Anonymous Coward
    ... C is only for old people!
    • Oh good, that means the pay for old programmers will go up again, like it was when the old people were doing the COBOL for the banks and the kids were using C.

      The last website I made, it was in C. Welcome to the IoT. Java is too fat to fit on a microcontroller, after all.

      I'm using C more and more all the time. I guess I'm getting old.

      Actually, when I search for stuff about C, I have to use other search terms, like the library I'm using, because "C" isn't a very unique substring. ;) Sometimes I even have to

      • by Dahamma ( 304068 )

        You don't need to use C for IoT. Probably the most interesting IoT SoC vendor around right now (Electric Imp) is using an interpreted language (Squirrel) to enable some pretty low level programming, and make it trivial to develop IoT apps.

  • by Big Hairy Ian ( 1155547 ) on Sunday January 08, 2017 @07:46AM (#53627635)
    Bear in mind almost all of the rival languages were written in C themselves and C is written in machine code most of us are programming in C and Machine Code anyway. In the end we're all writing Machine Code we've just wrapped it up in a nicer package is all
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Your compiler is programming in machine code. You just feed it hints.

      Feed your compiler some good hints and it might even write code to use the full width of those vector registers your processor has but you were ignoring.

    • by truedfx ( 802492 ) on Sunday January 08, 2017 @08:41AM (#53627771)
      C compilers haven't been written in machine code or even assembly for a long time, aside from a rare few. They've been written in C themselves for a while, but today's most common C compilers are written in C++.
    • @Big Hairy Ian

      In the end we're all writing Machine Code we've just wrapped it up in a nicer package is all


      Toggled in the binary code for any bootloaders recently? Addressed any registers lately in C? Dealt with any vectorising and prefetching in C in the past week? Inserted an NOP's in C recently to keep nasty timing stuff from hapening?

      No? Then you're clearly talking nonsense. The C virtual machine is way different from the processor it targets.

      Just as driving a car is different from deali

    • A lot of people don't realize it, but even emacs is written in C. That's why it has such a great LISP interpreter!

      On microcontrollers it is fairly normal to write the C, and then hand-tune the ASM that gcc outputs.

  • Oh gosh (Score:2, Insightful)

    by Anonymous Coward

    Not again.

  • Search engine? (Score:5, Insightful)

    by denisbergeron ( 197036 ) <DenisBergeron@yaho[ ]om ['o.c' in gap]> on Sunday January 08, 2017 @07:55AM (#53627653)

    Everybody that work recently with C IDE knows that you don't need search the web to find information !

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      Even without an IDE.

      C is simple enough not to need a lot of searching to find out how to do things - unlike nearly all the OO languages.

      Assembly got searched for more due to the shift from Intel to ARM. Also searches for Intel assembly grow due to all the crap intel has had to add to a poor instruction design to maintain "compatibility". If the RISC underpinnings of the X86 (both 32 and 64 bit lines) were accessible the speed would increase by 10-15%.

      • If C developers aren't searching for C info, they ought to be. People may think that C is simple, but it's full of hidden gotchas.

        For example, strncpy() doesn't actually do what any reasonable person would assume it does. Using it in the wrong "obvious" way can result in bugs that won't easily be found during testing. There are hundreds more land mines like that sprinkled throughout the C ecosystem, and they all need to be reviewed repeatedly before one can be considered an experienced developer.

        • eh, strncpy() doesn't do what the strncpy(3) man page says it does?

          I usually don't need a search engine since I have man pages for common C functions

          • That's nice that you have the optional local documentation installed for the C libraries, so you can find out that strncpy() doesn't do what any reasonable person would assume it does without searching the web. (Do you have the POSIX versions installed as well? Sometimes it conflicts with the Linux version, and both can be extremely vague. For those entries, you might have to start searching the web.)

            Not to mention that many if not most of the gotchas are in the core language, and man pages won't help you m

            • by syzler ( 748241 )
              What distribution has the libc libraries and headers available without the corresponding documentation?
            • Well, if you consider the man pages to be vague, maybe C just isn't for you? Maybe you should leave it to the old people, whose understand all that gobblygook.

              Also, if you're hitting C language gotchas, rather than library gotchas, you should probably just believe yourself to be less clever, and you'll stop doing it. Clever C code is also known as a bug. Let the compiler do the clever parts unless you're on a microcontroller and then you write the clever parts in ASM.

        • by syzler ( 748241 )

          For example, strncpy() doesn't actually do what any reasonable person would assume it does. Using it in the wrong "obvious" way can result in bugs that won't easily be found during testing. There are hundreds more land mines like that sprinkled throughout the C ecosystem, and they all need to be reviewed repeatedly before one can be considered an experienced developer.

          Knowing the prototype of "char * strncpy(char * dst, const char * src, size_t len);", my assumption would be that strncpy() would copy up to 'len' bytes of data from the 'src' pointer to the 'dst' pointer which probably does not include a NULL terminator if the 'src' string is longer than 'len'. As such, as a programmer I should pass 'dst_len - 1' as 'len' so I can ensure the 'dst' string is NULL terminated by calling "dst[dst_len-1] = '\0';" immediately after calling strncpy().

          If this is an unreasonable a

          • by gweihir ( 88907 )

            For any competent coder that understands how the machine actually works, this is a very reasonable assumption. And, in addition, it is documented in the second sentence describing srtncpy in the man-page under Linux, for example. How this can be called "hidden" or even a "gotcha" is beyond me. Of course there is this one large class of incompetents where it is always somebody else's fault.

        • by gweihir ( 88907 )

          "man strncpy" explains the gotchas:

                " Warning: If there is no null byte among the first n bytes of src, the string placed in dest will not be null-terminated."

          If you think they are "hidden", then you seem to have some problem with reading comprehension. So really, to strncpy one byte longer and zero the last one. If that is beyond your skills, please stay away from C.

        • Oh, I do plenty of searching when using C, but I wouldn't be searching for "C" I'd be searching for strncpy examples directly, without talking about C, and most of the results I'd be looking at would be code repos not paste sites.

          Also, lot of C questions will actually be questions about make or autoconf.

    • by gweihir ( 88907 )

      "IDE"? What is that? Is that like some poor-man's version of Emacs with man-pages integrated?

  • Bullshit metrics (Score:5, Insightful)

    by _merlin ( 160982 ) on Sunday January 08, 2017 @08:07AM (#53627683) Homepage Journal

    I don't use much straight C these days (mostly C++ with bits of Python, lua, PHP and other stuff for glue, and occasional C#), but the metric is bullshit. It's a measure of which languages are most suited to passing roadblocks using search queries including the language name. This tends to select for how much a language is used by inexperienced developers.

    I'm a pretty experienced C++ developer, so I'm unlikely to be putting C++ in search engine queries. I know the language and library pretty well. If I want to get reference for a particular standard library feature, I'll use a query like, "codecvt". If I want docs for a Linux feature (e.g. routing sockets or the capabilities API), I'll pull up a man page. If I want to know what some ioctl does and the docs are lacking, I'll look at the Linux kernel source. I'm not typing C++ into google when I'm doing my day job or open source work []. Same applies for other programming languages I'm competent with. I do bits of assembly language, but I'm not typing that into Google. I have user mode architecture manuals for the processors I need to deal with, and ABI manuals for the operating systems.

    On the other hand, I'm far more likely to put the name of a language I'm less familiar with and only use occasionally into a search query when I'm trying to find the conventional way to do something. Something like "C# confirm close modified document window", "python open subprocess stderr", or "php openssl rsa". I'm a clueless goon when it comes to available libraries and best practices for these languages, so I boost their TIOBE rankings on the occasions when I have to use them, while my bread-and-butter C++, assembly language and C don't show up, despite working in C++ for the bulk of my programming time.

    • by aepervius ( 535155 ) on Sunday January 08, 2017 @09:45AM (#53627927)
      A language is thriving or dying by the number of inexperienced developper trying to learn it. If no inexperienced cev learn it... it is dying. See the experienced dev of today were the noob of yesterday. If everybody is learning c# or java it is a pretty good indication of what the future of c, c++ will be. For reference see cobol. But rejoice , a dying or less used language means that for us the kldr gen, assured contracts works.
      • A language is thriving or dying by the number of inexperienced developper trying to learn it. If no inexperienced cev learn it... it is dying.

        But your thesis ("[web searches for help on a language is] actually a good metric [for language viability]") doesn't follow from that assumption.

        Other possible explanations include:

        "The C language is easy enough to understand, compared to others such as java, that references to documentation and searches for arcane knowledge about it, even by noobies, are rarer."


    • Re:Bullshit metrics (Score:5, Interesting)

      by Solandri ( 704621 ) on Sunday January 08, 2017 @10:07AM (#53627979)
      I'll add that every C/C++ IDE I've used has really good built-in documentation and search features. I've rarely felt the need to google something when programming in C/C++.

      OTOH when I was writing stuff in Perl or PHP, I was googling stuff constantly because the documentation is online and the sites' search feature sucks.
    • Re:Bullshit metrics (Score:5, Interesting)

      by GrumpySteen ( 1250194 ) on Sunday January 08, 2017 @10:15AM (#53628003)

      Search engine metrics are also flawed in another way; the worst examples of things often generate a lot of searches, but that doesn't mean they're popular. This metric would tell us that the most popular financial company is Wells Fargo []. They're at the top because of the news that they created millions of fraudulent accounts, however, and not because they're popular.

    • Straight language queries are rare for experienced developers - more telling would be queries for APIs. Even after 10 years using an API, I still google search for how some of the functions work, what's the order of the arguments, what are the available enum options. The API you query often gives away the language you are using.

    • I pretty much put the same ratio of queries into google to the time I am using it. The question would be how well my queries can be connected to my language. If I am using Python for the first time in a while my query will be something like "Connect to mysql with Python" but with C++ it will typically be a copy and paste of some strange linking error. Can that copy and paste be connected to C++?

      If my later query isn't being connected to C++ then the typically more experienced programmers aren't being prop
  • by Anonymous Coward on Sunday January 08, 2017 @08:07AM (#53627687)
    C is dying, Slashdot confirms it!
  • So developers get a chance to play with all the new shiny toys for a while.
    When the economy crashes again everyone will run back to the old tried and true, because they need to get work done.
    This is about the fourth or fifth time I've seen this happen during my career.
    Although IMO it would be nice to see something come along that could replace C for, e.g., kernels.
  • by dottrap ( 1897528 ) on Sunday January 08, 2017 @08:11AM (#53627699)

    I'm seeing a resurgence in C. It seems to be coming from several different directions.

    The first is from people like Mike Acton:
    CppCon 2014: Data Oriented Design []

    The second is from all the new languages like Go, Rust, Swift. All these new languages need libraries so they all built in good C interoperability so they could be useful immediately without requiring ground up new implementations of everything. So I'm seeing more new pure C libraries being created now than I've seen in a very long time. Library developers know that their libraries will be usable from every language if they write it in pure C.

    The third is from IoT. Embedded developers never left C. Now with IoT growing, C lives on.

    In all of these cases, they might fly under TIOBE's radar. Most of these people probably don't need to search for C. They already know it and are too busy working on their projects.

    • by DrXym ( 126579 )

      Library developers know that their libraries will be usable from every language if they write it in pure C.

      Library developers know that their libraries will be usable from every language if they write it in Rust too. With the added advantage that the code is liable to be far more stable and reliable.

    • So I'm seeing more new pure C libraries being created now than I've seen in a very long time. Library developers know that their libraries will be usable from every language if they write it in pure C.

      But that still marks a shift away from C in "macro" development. C's a good choice for small, self-contained chunks of code that are likely to be reused frequently, but the bulk of dev work is specialised glue logic for a particular app -- probably a Temple Run clone. Nobody's going to write a Temple Run clone in C.

  • by Rufty ( 37223 ) on Sunday January 08, 2017 @08:14AM (#53627709) Homepage

    They're much more like: "Why does processor X on board Y rev1 have I2C on those pins, but on rev2 accessing those causes a reboot. Who thought that was a good idea? Can I LART them? And how can I detect board version in software?"

    • And how can I detect board version in software?

      Try accessing the I2C pins. If you get a reboot then you know you're on rev 2.

  • by isj ( 453011 ) on Sunday January 08, 2017 @08:17AM (#53627719) Homepage

    "i-programmer suggests this could just be an artifact of the way TIOBE calculates language popularity (by totaling search engine queries). "

    The TIOBE index is not based on the number of queires (see []).

    It is based on the number of results on the query " programming" in multiple search engines.

    So the TIOBE index is "how much has been written online about "

  • C isn't really used / chosen any more to participate in the international dick-waving contest. I hope in many ways C is falling out of favour with people just trying to "be cool" or using it for tasks that it's ill suited for.

    Regardless of C falling in popularity (if legitimate) it's unlikely to be buried any time in the next 50 years given its use in the core of everything from OSs to 1K microcontroller firmware.

    • Regardless of C falling in popularity (if legitimate) it's unlikely to be buried any time in the next 50 years given its use in the core of everything from OSs to 1K microcontroller firmware.

      Just like COBOL, although I still think that COBOL programs will decline in percentage of business computing as time passes. As a sidenote, I find it sad that C is used in 1K microcontroller firmware. Where would it payoff in either space efficiency or developer "friendliness"?

      • by inflex ( 123318 )

        C for modern microcontrollers is a good mix. Easy to access bit-level operations (port control, bit bashing etc) but providing structured programming framework with easier debugging (libraries, function calls, interrupts, even portability to other architectures).

        I code ASM for quite a few when needed (ie things like the Attiny5/10 due to stack limitations ) but realistically doing it in C makes the end-to-end development process a lot smoother.

        The compiler will out optimise the human in almost all cases, a

        • I look at computer languages as a designed tool to best express what the programmer wants accomplished. If the programmer has to conform to the tool, or recreate the wheel every time they program something, or have to relearn how to do things in the language in order to do something useful, then its not a good tool/language. C has the ability to interface with assembly, and it has some higher level abstractions which makes programming easier than assembly. But for a 1K chip, you probably have to discard

    • by raymorris ( 2726007 ) on Sunday January 08, 2017 @09:02AM (#53627813) Journal

      Quoting TFS, "t is not a language that you think of while writing programs for popular fields such as mobile apps or websites". Submitter clearly doesn't have much idea how web sites work. For web sites, your browser (a C or C++ program) sends a request through routers running Cisco iOS (a C program) to a web server such as Apache (a C program), which may run a module such as mod_php (a C program) which in turn probably runs a library such as ImageMagick (a C program) which generates the content. The content is fed back through the web server (still C) to your browser. For larger sites, there is often a proxy in the middle, such as Squid (written in C) or mod_proxy (more C).

      • When you're writing a mobile app or building a website, you are not writing compilers, browsers, router firmware, web servers, PHP interpreters, proxies, or even libraries for 3rd party use. If you are writing libraries, chances are that you're writing these for your own use or your team's, probably in the language you're building the rest of the app or website in.

        Languages that do come to mind in these fields are Objective-C, Swift, C# or Java for mobile apps, or Javascript, Java, PHP, Ruby or C# for w
  • Betteridge's law (Score:4, Insightful)

    by fnj ( 64210 ) on Sunday January 08, 2017 @08:26AM (#53627731)

    Betteridge's law of headlines. Answer is no. HELL no. Hell no, you royal asshole. Discussion terminated. OK?

  • C is a very small language with a modest standard library. The language itself has ANSI and ISO certifications. The standard C library is largely defined by POSIX. I con't have to hold much in my head by way of language constructs or reserved words, etc. and any other programming languages derived their syntax from C, so it will get reenforced often (except the weird ways to use pointers).

    If I have a question about a standard libc function, the man pages will be there on my systems whether it is FreeBSD,

    • by gweihir ( 88907 )

      Indeed. And maybe the one most important thing about C plus Unix is that the number of special things you need to learn and understand is limited.

      Sure, once you tackle, say, socket programming for the first time, it is tricky and obscure. But once you have it, it will stay the same forever, and you do not need to re-learn it all the time because every more abstract language hides features, translates behavior and adds its own things. So far I have not found any abstraction of such concepts that did not make

  • C is still basically the most widely used assembler 2.0 and just about everything we use is built with C.
    Yes, there is C++ and entire stacks built on that, but I'm not talking about Windows. In the global context, Windows is somewhat of an exception.
    The C familly of languages is alive and well and the C-fans building our systems we work on still seem to think it's the best tool for the job.

    Until someone replaces the entire toolchain with a new language like Go or Rust and people from the format like Linus T

    • by gweihir ( 88907 )

      Rust and Go cannot cut it. When you really need full control, they are just as unsafe as C, but they are not as clean or clear.

      • When I hear someone blah blahing about either of those languages in a serious way, I just think, "Good luck finishing any project bigger than a year end university project." Then good luck when both of those languages slip into obscurity. And good luck finding experienced programmers in either of those languages. And good luck finding commodity tools for either of those languages like Coverity.
        • by gweihir ( 88907 )

          It is the "Silver Bullet" mindset. Its proponents think that if they just had the right magic tool, all problems would go away. Well, Brooks published "No Silver Bullet" in 1986, and these people are not only clueless and incompetent, they are unaware of history. This is just as true today as it was back then. There is no silver bullet, no magic language or tool that will ever make a wannabe a competent engineer. On the other hand, competent engineers can be slowed down by sub-optimal tools, but that is abo

  • TIOBE index ist not significant for the popularity (what ever that may be) of programming languages.

  • Just like real programming!
  • I respect the TIOBE index's goals, and I wouldn't be surprised if C actually is declining. It doesn't scale well with modern day projects, is a frightful source of bugs, and can be pretty tricky to work with between OS's. That being said, C is still an extraordinarily useful language, and I wish we taught it and encouraged younger programmers to learn it; for its many faults, it also has many virtues, especially its simplicity. Combined with its power and massive supply of existing software, it'd behoove a
  • by Proudrooster ( 580120 ) on Sunday January 08, 2017 @10:23AM (#53628025) Homepage

    C is not dying. Most of the libraries that are used behind the scenes to support Swift, Objective-C, Java, Python, Perl, LINUX, C#, and New Embedded Platforms like PI, are all written in C/C++.

    C scales as well as any other language as long as you use C++ and objectify everything so it can fire it up in containers. You can't use global variables anymore and everything needs to be encapsulated into an object. It pains me to do this, but with the shift to the cloud there is no choice (please prove me wrong).

    C is the bed-rock of all that is digital. If anything needs to die it is Java. The new owner of Java doesn't seem to be taking care of it like Sun Microsystems used to. Yeah, I am looking at your Oracle.

    Consider how many C libraries this Slashdot page passed through just to get to your eyeballs.

    • Wait, why do containers require you to not use global variables?

      If anything needs to die it is Java.

      If Java dies, it will be replaced by C#. So not much change.

    • I really hope that Java continues to thrive. There is a certain type of pedantic bureaucratic programmer that finds a happy home in Java. I really don't want them leaving that steaming rathole and bringing their stink into other languages. Someone mentioned that they would go to C# but that is more of a language for those who have no souls and are willing to let MS do their thinking for them. Java allows them to be all self-righteous while the rest of us can completely ignore them. When I see the words JVM
  • by Harold Halloway ( 1047486 ) on Sunday January 08, 2017 @10:30AM (#53628037)

    ...since D was released.

  • by JoeyRox ( 2711699 ) on Sunday January 08, 2017 @11:00AM (#53628117)
    C is not the next great thing. But is still the one of the best things and will always be a workhorse.
    • by gweihir ( 88907 )

      Unlike languages targeted at barely competent programmers (like Java), C demands insight and understanding or things break very fast. That will always limit its popularity. On the other hand, those few that have the skills will continue to use it, because nothing else gives you remotely the same power and simplicity. Sure, glue-code where performance does not matter is better written in a scripting language like Python, but for the actual work nothing beats C written by somebody that knows what they are doi

  • by cpghost ( 719344 ) on Sunday January 08, 2017 @11:57AM (#53628329) Homepage
    C isn't dying, but I think that it is being slowly replaced more and more by C++. Not all of a sudden, but when new code gets added, it is just more convenient to use std::string, RAII, the whole C++ Standard Library. Especially since C++11, C++ and its library have matured a lot to actually become useful and have you write beautiful and fast/efficient code, thanks to move semantics. So no, C isn't dying, it is morphing into C++11 and later. Even for embedded and kernel-level programming: check out recent projects: many use C++, carefully avoiding features like virtual functions that would slow down running time. It is as good as C can get, only better.
    • by gweihir ( 88907 )

      C++ is actually a barely usable monster. It adds nothing real except complexity, also because its OO model is fundamentally broken and inefficient. Sure, C can benefit from some libraries like safe string handling, but that is it. So, no, C is not "morphing" into C++ at all.

  • No.

    If the fuckwit who wrote this shitpost can't be bothered to do enough research into either the topic or have the journalistic integrity to posit a theory, and instead needs to shitpost a question...

    Then as always, the answer to the headline is no.

    • by Mybrid ( 410232 )

      Also, why does it matter? Tools are not a popularity contest. Pick the right tool for the job. Haskell has found a niche in MQ and async communication. Okay then. The only discussion on this topic that is relevant is about the applicability of a tool.

      For example, NodeJS is crap. The crap though has nothing to do with the language "Javascript" but the server-side implementation of NodeJS.

      Or PHP. PHP's security model has always been suspect more than that of other languages and yet is a one of the most widely

  • That is what I seen. I can't remember the last time I saw a job ad for just C.

  • That's to say: no, it isn't.

  • hardly suitable for the booming fields of web and mobile app development.

    Perhaps this is so. But embedded apps are largely written in C.

    Some years ago, I ran across a statistic. I'm not sure if its still accurate but: Take all the processors used in personal computing devices (PCs, tablets, phones) and web servers as a subset of all processors, micro-controllers, etc. and calculated that as a percentage. Rounded to the nearest whole percentage point, that number would be zero.

  • Results within 25 miles of my residence at Indeed (full-time positions only):

    C: 1440
    C++: 474
    Python: 762
    Ruby: 336
    Java: 1113

    I suspect the results for "C" are inflated due to the difficulty of isolating only positions looking for the "C" programming language. Same exercise at Stack Overflow jobs:

    C: 2
    C++: 2
    Python: 10
    Ruby: 7
    Java: 14
  • There are quite a few things that cannot be reasonably done in any other language. Also, because it is closest to the machine without being assembler, any real IT expert will have C-skills. It makes a world of difference.

  • C is by far not the worst of them but there are languages that just seem to be asshole magnets. Pretty much no matter what your coding/commenting style is, any mostly C programmer will not only try to tell you that you are wrong but will try to get you fired along the way. This is the sort of thing that really puts off new programmers.

    Just to make C people feel a little better, they are saints compared to anyone who claims to be a CSS programmer (are they seriously claiming to be programmers) or the worst

Basic is a high level languish. APL is a high level anguish.