Is The C Programming Language Declining In Popularity? (dice.com)

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 Dice.com 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?

Comments

In Korea ...

[Anonymous Coward]

... C is only for old people!

Re:In Korea ...

[phrostie]

Maybe, I remember thinking the same thing about Assembly and Machine code, but my dad made a living at it for decades.
In university(in the 1980's) one of my advisors told me not to take C.
He said it was a fad and would never catch on.

Re:In Korea ...

[Aighearach]

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 throw in a library I'm not even using, just to narrow the search terms to C. And for microcontroller stuff, C is actually spelled "avr-gcc" or "ESP8266 sdk".

Re:In Korea ...

[Dahamma]

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.

Re:In Korea ...

[Aighearach]

If you don't think in absolutes, then your comment has no value. The existence or possibility of alternatives changes nothing that I said.

You don't "need to use C for IoT," but you do need to use C for many specific microcontrollers that power IoT devices. Sure, you could just spend more money and get a device that can run more things. Sure, you can also use Lua on the ESPy. You don't get the same performance, though. How trivial it is to buy different hardware is irrelevant; smaller is cheaper, cheaper in this niche is going to mean that most of the tools are in C. The lack of supporting tools and libraries for your alternatives might cause them to even take longer to develop with!

You might find the Brandybrand(TM) that you mentioned to be the most interesting, but I would counter that a ~$30 device that does less than a $6 ESPy is not really a great example of alternatives being viable. They certainly can and will exist, but at the hobbyist level. That thing is competing with the raspberry pi for the "I want to do it myself but I don't know how to do it" market. That is not the same thing as the IoT market.

Re:In Korea ...

[Dahamma]

No, if you graduated in 1998 (assuming you mean college) you are not in ANY reckonings a millennial. You are literally borderline OLD PERSON!

But beyond that, check out the language. It's basically Lua but really good.

Re:In Korea ...

[Dahamma]

The last website I made, it was in C. Welcome to the IoT

This comment is ignorant.

If you don't think in absolutes, then your comment has no value.

This comment means you didn't understand mine.

Yes, obviously, a decreasing but still important share of the market is using C (THAT'S THE POINT OF THE ARTICLE!) My point was IoT will NOT be a resurgence of C, it will be a small amount of core OS/middleware programming in C (which is what it was meant for) and a ton of programming in an efficient higher level language.

Re:In Korea ...

[Aighearach]

The last website I made, it was in C. Welcome to the IoT

This comment is ignorant.

That's one of the most ridiculous things you could say. How could I possibly be ignorant of the details of my work, and why would you know better what I did?

Yes, obviously, a decreasing but still important share of the market is using C (THAT'S THE POINT OF THE ARTICLE!)

No. That is not the point of the article at all. The point of the article is that searches for help on C that list themselves as being for the C language have decreased. Trust me, C programming requires much more careful understanding of details than you're showing. Are you sure you have enough knowledge to be talking about this one?

Re:In Korea ...

[Dahamma]

That's one of the most ridiculous things you could say. How could I possibly be ignorant of the details of my work, and why would you know better what I did?

Not talking about your work, the "Welcome to the IoT" was what I felt was ignorant, of course. IoT is not about C these days (in terms of volume) if you are paying attention. It's about a tiny (C based, for an interpreter, etc, of course) kernel and tools and a HUGE higher level ecosystem.

The point of the article is that searches for help on C that list themselves as being for the C language have decreased.

No, that's the *methodology* of the article, but the *point* was that C is declining in overall popularity as a total percentage of programmers.

I don't want to get into a pissing match on C/C++ programming, but I'm pretty sure I have plenty of knowledge on C/C++ in the embedded space. I'll just say any Smart TV, BD player, and most STBs that stream video in the past 6+ years (300M+? Maybe more?) have many lines of C/C++ code I wrote in them.

Re:In Korea ...

[Aighearach]

"Welcome to the _____" means that the thing is part of the experience there. There is nothing exclusive; if it meant that was the only thing there, it would require more words. Words that I didn't include.

If you think that C code on IoT devices is just for running an interpreter then my advice is to look past the ESP8266 because as awesome as it is, and as cool as Lua is, most products using the ESP are using C, and there is a very popular C webserver for it you implement the dynamic elements as C callbacks. That is the sort of thing that is driving IoT, and most of the IoT chips don't even have popular interpreters ported to them! You say you've got video code on embedded devices, that's nice but those are high powered systems compared to the cheap ICs necessary for IoT. If you're doing video, you need resources, and you can use a lot more normal types of coding techniques and preferred tools to get the job done because they use less than video. IoT is about having a very small amount of resources.

And no, you can't separate the methodology of their test from the implications. That is true of any sort of test or study; the details of what was studied sets the stage for what you can claim that it shows. A methodology based on web searches can't actually tell you about popularity unless you have really extensive data on confounding variables, and nobody has that here. So you can't improve the data quality enough to make that sort of claim. You can't even make that claim! It isn't available. All we know is that searches changed. It could be as simple as, some percent of searches for C used the word "Arduino" instead of "C" and there wasn't even a change in actual searches. That's how broad and unresolved the confounders are. The idea that it might be less popular isn't even a hypothesis, it is just an idea thrown at the wall that might explain it. Or might not.

We're all programming in Machine Code

[Big Hairy Ian]

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

Oh gosh

[Anonymous Coward]

Not again.

Re:We're all programming in Machine Code

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

Search engine?

[denisbergeron]

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

Re:Search engine?

[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%.

Re:Search engine?

[Anonymous Coward]

On Linux:
C -> man pages
C++ -> web search
Python -> web search

Re:Search engine?

[Waffle Iron]

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.

Re:Search engine?

[iggymanz]

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

Re:Search engine?

[Waffle Iron]

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 much there.

Re:Search engine?

[syzler]

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 assumption, what is a reasonable assumption?

Re:Search engine?

[syzler]

What distribution has the libc libraries and headers available without the corresponding documentation?

Re:Search engine?

[gweihir]

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

Re:Search engine?

[gweihir]

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

Re:Search engine?

[gweihir]

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.

Re:Search engine?

[Aighearach]

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.

Re:Search engine?

[Aighearach]

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.

Re:Search engine?

[Waffle Iron]

Yes, you would naturally assume that best practice is to artificially adjust the buffer length, and to execute a separate statement to add a null char *every* time you call one particular library routine, especially if most every other library routine that starts with "str" does set the null terminator unconditionally and doesn't require you to fudge the buffer length.

Or at least you might assume that if you were an imbecile.

Re:Search engine?

[Waffle Iron]

It the function were named "copyTeminatedStringTo_UNTERMINATED_memoryBuffer()", then you'd have a point.

As it is, this non-string function is named just like all of the actual terminated string functions. So you can save your insults; *I* know about this C library fail (along with scores of other fails), but this problem usually crops up multiple times in any significant project with more than a couple of team members. So much so that it's best to prohibit the use of this function altogether in coding standards, and replace it with a home-grown function that does what people actually expect.

Attempts to "fix" the problem by fudging the buffer and setting characters are just asking for fencepost errors. Not to mention the performance penalty for needlessly zeroing out any empty space after the string.

Re:Search engine?

[iggymanz]

Nope, you're the one that isn't reasonable. The function does exactly what the doc says, and those of us who code in C have the correct docs for our libraries.

gotchas in the compiler? Nah, they're well documented too. ANSI standards, compiler extensions....

Re:Search engine?

[gweihir]

Attempts to "fix" the problem by fudging the buffer and setting characters are just asking for fencepost errors. Not to mention the performance penalty for needlessly zeroing out any empty space after the string.

No, they are not. They are what you do if you are competent. There is no "fudging" here, just sound practices. This is however C not Java, so do not expect a nice verbose safety net. Your proposal of "copyTeminatedStringTo_UNTERMINATED_memoryBuffer()" already shows that you may know some C, but you do not get it at all. For starters, the first part of the name is wrong as strncpy can and will be used to copy non-terminated strings. Also, the termination is never the task of a buffer, so the second part of the name is just as wrong. Please leave and go to your walled garden where everything is safe an nice (and a slow memory-hog), we real coders have work to do.

Re:Search engine?

[Waffle Iron]

As I said, "sound practice" involves not using that damned function at all. Why do you defend the design of an API that requires you to add an extra line of mitigation code every time you use it?. And why would you accept the performance hit of the extraneous zero padding? It's most likely worse than any of the bounds checking you're so worried about. But an actual "real programmer" would know that.

Re:Search engine?

[syzler]

If a C string array needs to be NULL terminated, then a 16 byte array only has 15 bytes of usable string storage. How am I artificially adjusting the buffer length by telling strncpy() to copy at most 15 bytes of data?

Let's take another approach. Let's assume I need to copy of C string into a fixed length array as might happen with a binary protocol. If strncpy() automatically NULL terminated the string, then I would be unable to use every byte of the fixed width field as one byte would always be consumed by the superfluous NULL terminating character (unless, of course, I write my own function).

In its current form, strncpy() can be used for copying strings into fix length fields or into another string array without the need of two functions.

Re:Search engine?

[gweihir]

The design of strncpy is not bad, it is specialized. This is not a function to be used for every case of a string copy. Now, the only thing you could accuse strncpy realistically of is bloating the API. But the C string API is small enough for that to not really matter.

Re:Search engine?

[Waffle Iron]

So you've avoided the need for another function by requiring the user to add *two* separate manual fixups to each call of the most common use case. Do you realize how stupid that is?

Of course, the best practice is to forbid the use of strncpy at all in coding standards, which then involves what you said you wanted to avoid: writing your own function.

I'm not the only one to point this out. Here's the discussion of strncpy from Wikipedia:

Despite the well-established need to replace strcat[10] and strcpy[6] with functions that do not allow buffer overflows, no accepted standard has arisen. This is partly due to the mistaken belief by many C programmers that strncat and strncpy have the desired behavior; however, neither function was designed for this (they were intended to manipulate null-padded fixed-size string buffers, a data format less commonly used in modern software), and the behavior and arguments are non-intuitive and often written incorrectly even by expert programmers.

Re:Search engine?

[HeckRuler]

People may think that C is simple, but it's full of hidden gotchas.

Compared to what?

EVERY language is full of hidden gotchas. Doing shit behind your back under the hood which works 90% of the time but the remaining 10% will eat 99% of your time. Dynamic typing which lets you work REAL fast without having to worry about types, until you do, at which point you have to consult a mystic to determine just what the fuck is going on.

If you want to start talking about what "reasonable people would assume", you've got a shmorgas board of variation in the human condition that keeps any group of 5 or more from agreeing about how things ought to be. strncpy copies a string for 'n' characters. If you don't understand null characters, C and strings might not be for you. And yeah, that is something that the language could handle for you if it assumed a certain desired behavior. And that'd work 90% of the time.

But name me a language which doesn't have hidden gotchas.

Re:Search engine?

[david_thornley]

I can also accuse strncpy() of polluting the namespace and taking up a name that would ideally be for a length-limited string copy As it is, it's a special case a programmer has to remember.

Re:Search engine?

[gweihir]

If you expect a general string-copy function in a language like C that does not really have native strings, but just a convention in the native libraries, than the problem is in your side. Incidentally, if you expect a "strNcpy" to be general, then there is an even bigger problem on your side, as there is no way to generically shorten a string to a given length. There is always a range to chose from. What you probably want is strdup(), which indeed does copy any string, but it does not copy into a provided bufferer, which is the whole point of the str*cpy functions.

Seriously, C is not a beginners language. Go play with Java or the like and stop complaining about things you do not understand.

Bullshit metrics

[_merlin]

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 site:en.cppreference.com". 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.

Re:Bullshit metrics

[Solandri]

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

[GrumpySteen]

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.

Re:Bullshit metrics

[Anonymous Coward]

New languages also tend to have crappy unorganized documentation, which in turn creates more queries. This explains the sudden rise new languages sometimes experience in the index, which tends to stabilize to a slow decline later once someone cleans up and improves the docs.

Re:Bullshit metrics

[JoeMerchant]

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.

Re:Bullshit metrics

[EmperorOfCanada]

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 properly counted and they are the ones doing the "real" programming of things that make the world go around. I love parts of python, I love parts of PHP, I use them for some small things. But for my "real" work that if not done would have a measurable economic impact it is C++ all the way.

C is dying...

[Anonymous Coward]

C is dying, Slashdot confirms it!

Re:C is dying...

[GrumpySteen]

I'll wait for the microfiche at midnight.

Yup, the economy is good.

[darthsilun]

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.

Re: Yup, the economy is good.

[darthsilun]

Thank you Captain Obvious.

You neglected to tell us that C is portable, and assembly is not. One of the big points of the Unix and Linux kernels is that there is very nearly no assembly.
Also I don't really buy your statement that OO languages lack predictability in execution. While I would probably not suggest C++ for a kernel, my use of it – for storage software – did not not exhibit any unpredictability. To be sure, we used a very limited set of C++ features, and perhaps there are features we didn't use that might cause the unpredictability you're referring to – ymmv. I also have knowledge of another Open Source storage project written in C++ that uses every fricken last feature of C++ there is, and I have have heard a lot of things about it, but never that it had unpredictable execution. It's slow, but it's predictably slow.

I couldn't tell you about Rust, Golang, or Swift, as I haven't used those very much. Java's object ref counting and garbage collection seem like they'd be a can of worms – even if you were using a native compiler like GNU gcj – maybe that's what you're referring to.

I'm seeing a resurgence in C

[dottrap]

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
https://www.youtube.com/watch?...

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.

Re:I'm seeing a resurgence in C

[DrXym]

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.

Re:I'm seeing a resurgence in C

[EmeraldBot]

"New languages"?

Pssht! As if!

Man, there's so many varieties of Object-Oriented C you could jizz your pants without even touching yourself.

C is the Primal Language. Before C we have clicks and whistles.

This isn't even a fucking conversation. I'm not hearing what anybody says except my own opinion, because I know my opinion is right, so this isn't a conversation.

What did that dude say in "Fight Club"? "This. Conversation. Is. Over."? Right? Well man thissuh conuhversationuh isuh nottah happenun.

This is some bullshit. Fuck, there are HLA interpreters that are more popular than JAVA -- WITH PEOPLE WHO KNOW HOW TO CODE.

Man this is so much bullshit. I can't believe there's no viewpoint, no slant, no perspective, no synonym of whatsoever with this article.

That's the new owners of Slashdot. This site is dead. If you can diss C because some homie of yours called you up and needed some help raising interest in some particular market, towards a hopeful stock point, maybe on some IPO to come, maybe on something pre-existing, then fuck it, it ain't news any more, man, and it ain't for anybody but the "business school" {nested: "nerds"}.

When you say things like "This isn't even a fucking conversation. I'm not hearing what anybody says except my own opinion, because I know my opinion is right, so this isn't a conversation" and "What did that dude say in 'Fight Club'? 'This. Conversation. Is. Over.'? Right? Well man thissuh conuhversationuh isuh nottah happenun.", It becomes blindingly obvious you are either high on drugs, drunk with some shots I would pay to learn the composition of, or suffer an untreated case of a narcissistic personality disorder combined with the temperament of a three year old, because this is a public. forum, not your personal soapbox. You want to rant on about how unfair a major index has ranked a language you imply you know very little about, without any rational debate, feel free to take it to your Twitter page.

Oh. And uh, while I personally believe it's unethical to provoke those who are (at least at present) mentally incapacitated, I thought I should show you a little what the previous owners of Slashdot, Dice, ran a few years ago. I can sense the sound of your head exploding, eh?

Re:I'm seeing a resurgence in C

[darthsilun]

C is the Primal Language. Before C we have clicks and whistles.

Before C we had B, and APL, PL/1, Cobol, and Fortran, just to name a few.
Come up for air sometime, it really helps clear your head.

Re:I'm seeing a resurgence in C

[Half-pint HAL]

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.

Re:I'm seeing a resurgence in C

[Anonymous Coward]

Before C we had B

Are you Brian Kernighan?

Re: I'm seeing a resurgence in C

[DrXym]

Rust is open source, just like GCC, clang, llvm etc. Feel free to review it, or compile your own version if you're so paranoid.

Re: I'm seeing a resurgence in C

[Trailer Trash]

And lisp, don't forget that.

Re:I'm seeing a resurgence in C

[darthsilun]

Before C we had B

Are you Brian Kernighan?

No

Re:I'm seeing a resurgence in C

[darthsilun]

Before C we had B

Are you Brian Kernighan?

No

Brian has a beard. I don't.

Re: I'm seeing a resurgence in C

[superdana]

Ah, Lisp—the recumbent bicycle of programming languages.

Re:I'm seeing a resurgence in C

[DrXym]

That's the case for Rust. It has a foreign function interface that is basically just methods exported in a way that C expectant applications can link to. Providing the client has C headers corresponding to the .lib it is linking to it becomes completely ignorant of what the libs was written with - Rust, Haskell, anything.

Re:I'm seeing a resurgence in C

[DrXym]

C works anywhere (* subject to a massive list of restrictions and caveats). And the keyword here is "competently written C code". Rust kicks your ass if you do stupid stuff well before the code gets in production. It's frustrating when you're learning the language but the result is code that simply doesn't fail in the ways that C or C++ does all too frequently - memory leaks, dangling pointers, data races etc.

And perhaps people will stick with C longer that Rust. That doesn't make much of an argument for a library being written right now. Nobody would backport a Rust library to C. The rust compiler will exist as long as C does. There is no reason whatsoever to go with a retrograde language for what may or may not happen some unspecified time in the future. If that argument made any sense we'd be coding in BCPL, or assembly. You know, just to be safe.

Re:I'm seeing a resurgence in C

[DrXym]

There are plenty of ways to check C code.

Yes. An entire cottage industry of linters, post mortem analysis tools etc. to try and figure out what your code is broken. Too bad if that happened in production on a customer machine and now they're pissed and you're going to spend hours trying to isolate why the code is leaking / racing / crashing because of it.

Code that wouldn't have been broken in the first place or neded to have been fixed if the compiler could catch it. Which is what Rust aims to do insofar as it can.

These are problems with the programmer, not with the language. A programmer who makes code with such defects will find ways to make code in Rust or any other language fail.

No, they're problems with the language. Even the most seasoned, experienced C and C++ programmers fall afoul of these issues. Don't pretend you don't. I write C and C++ all day long and I still waste days debugging stupid shit that shouldn't have happened. And of course seasoned, experienced C and C++ programmers don't become that way without writing a LOT of bugs.

That is irrelevant when it is no longer supported. With C, you have almost complete certainty that you can use the code for many decades to come. With Rust, it is very doubtful that any supported tools will still exist in ten years.

Why is it doubtful? That's you projecting when there is no indication that Rust is losing popularity.

My problems programming in C aren't C related.

[Rufty]

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

Re:My problems programming in C aren't C related.

[serviscope_minor]

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.

The problem with the metric

[isj]

"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 http://www.tiobe.com/tiobe-ind...).

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 "

Re:The problem with the metric

[Raenex]

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

And even that simple measure is subject to false positives (like "C" being a common letter), and the results are "tuned" by TIOBE in an undisciplined manner to try to overcome this and other various problems with using "number of hits".

There are other measures of language popularity, including job offers, books, forum messages, etc. Using TIOBE as a single source and not trying to correlate with these other measures is a waste of time.

Does it really matter?

[inflex]

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.

Re:Does it really matter?

[slashdot_commentator]

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

Re:Does it really matter?

[inflex]

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, and if you have a specific block that you absolutely have to code in ASM then you can simply inline it within the C. If you need to ilk out that last few bytes in the flash then it's often cheaper to bump to the next uC size than pay someone to stuff around for days trying to out optimise (most optimisations will tend to be through algorithmic / process changes), not to mention dealing with the inevitable quirks/pains when someone tries to modify it.

Re:Does it really matter?

[slashdot_commentator]

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 stuff like stdio just to get code to fit in that space. And while its easier to get a C programmer to do something useful for that chip (because at least they know C), that C programmer will probably have to learn a boatload of esoterica (ways of doing things) for that environment to be an effective developer. If the programmer is the least bit sloppy, the C compiler will allow a completed binary to be larger than the available working environment. Therefore, C is not a language defined to help a programmer create code while the language helps manage the environment's constraints. (I wish I knew what the term was...) Ideally, there should be language for 1K chip environments to significantly ease development, but I guess assembler would be the only alternative that could fit the bill (unless you can use FORTH).

Betteridge's law

[fnj]

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

Reasons: standards, size and man pages

[bsDaemon]

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, Solaris or Red Hat. Most of the time, a question about C can be equally expressed as a question about Unix-like systems because of this.

C and POSIX are well established and have been through a rigerous standards process, so unless you're interested in a fancy new compiler feature like SafeStack on clang/llvm, you don't really have a lot to learn or relearn once you have it down. No one is about to change how C represents strings or any of the like between versions of compilers for reasons of "just because," though. You may need to look up the specifics of a third-party library if it didn't come with man pages, but that might not show up as a search about C.

Other languages with huge base libraries which aren't part of the OS's standards definition, multiple programming paradigms, lack of standards causing if shifts between versions, etc., are almost certainly going to get more people heading to Google because they have to.

Re:Reasons: standards, size and man pages

[bsDaemon]

You're right, but given that I was typing with my thumbs first thing in the morning before coffee, you get the point I was making none the less.

Re:Reasons: standards, size and man pages

[gweihir]

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 things worse, once you moved past toy examples.

Hence, sure, C has a really steep learning curve. But it stops pretty soon and then you need to understand algorithms and concepts and the problem that you want to solve, and C is merely the tool that does not stand in your way, unlike so many other programming languages.

Maybe. But what's the point of your question?

[Qbertino]

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 Torvalds start building systems with it, C might fluctuate in general popularity, but it won't go away.

Re:Maybe. But what's the point of your question?

[gweihir]

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.

Re:Maybe. But what's the point of your question?

[EmperorOfCanada]

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.

Re:Maybe. But what's the point of your question?

[gweihir]

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 about it.

Re:Maybe. But what's the point of your question?

[EmperorOfCanada]

Have spent, am spending, and probably will spend a good chunk of my career: trying to convince people not to use silver bullets, to stop using the silver bullet, or cleaning up after their silver bullet has given everyone lead poisoning.

My present fight: Sencha. What a bleak pile of silver coated excrement that product is. You will be 60% in the first 10% of your project. But you will never ever get past about 70% done unless you allow your definition of done to become very fuzzy. The key to their success is that if you look at any given problem that a team might encounter with Sencha there is a Sencha solution that looks good on the surface; except that in the context it was a Sencha workaround that required the creation of the problem in the first place; thus solving it becomes impossible without breaking something else. Thus the solution to any given problem soon becomes mutually exclusive to actual forward progress.

It becomes the scenario you are stuck in the mud and after spinning your tires for a while forward, some "expert" will suggest reverse. Except that the only real result will be spraying mud in another direction.

I just give up arguing with Sencha religious zealots who then defend many of its major defects as virtues. For instance there is only one real look and feel and that is from Windows circa 1995. Zealots will say that this is what most customers are comfortable with and it saves development teams from having to make design decisions. Or if you point out that it is slow as crap running uphill, they will say, "Any enterprise user will have new hardware."

Not again

[prefec2]

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

Re:We're all programming in Machine Code

[truedfx]

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

Re:Fuck You New Slashdot Owners, Fuck You

[EmeraldBot]

You're so busy fucking yourselves, maybe all you need is a good hearty fuck you to shut your stupid ass the fuck up.

Really contributes to the discussion, a fantastic way to convince someone you are a reasonable person with a well thought out position.

Why don't you go ask mother fucking ANSI what they think about C's popularity?

I'm not sure what ANSI is supposed to help us, all they do is set standards. May as well as IEEE what they think of TCP's popularity.

Why don't you go around and check to see what code is compiling and executing?

This is so vague as to being entirely meaningless, but alright. Javascript is considered the world's #1 compiled language. Java bytecode comes after. Maybe Shell scripting or Python after that. Aside from how asinine and useless those measures are, since they tell you nothing about its popularity with developers, it seems awfully strange to pick a fight with a language that is only ever compiled once and never formally executed in its original form.

Why don't you fucking just learn a tiny little bit about the history of programming languages and their derivatives

I'm not sure what the history of programming languages is supposed to do about what today's measures are, given that how it scored in the past has little bearing on how useful it is today. I'm completely confused as to what you even mean by that, or why you even put it in here. Perhaps, because like the rest of your post, it was entirely devoid of any rational point or argument?

your stupid caking piehole about shit that you shouldn't even be propagandizing about, stop dumbing people the fuck down, and just to reiterate, the the fucking holy hell up?

You state things much more bluntly then I would like, but at its core, perhaps yes. If you have nothing to contribute, take your meds, knock yourself out, and stop vomiting yourself all over this page.

Re:We're all programming in Machine Code

[Anonymous Coward]

C is a portable shorthand for assembly language.

Submitter is clueless - 99.9% of web sites run on

[raymorris]

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

Sure it is

[aglider]

Just like real programming!

Ehh...

[EmeraldBot]

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 new programmer to at least consider learning it, even if it really is declining in popularity (always an iff-y proposition with an index that's fundamentally slanted against languages requiring little documentation or online consults).

Re:We're all programming in Machine Code

[Anonymous Coward]

Better hurry before it's all gone,.

actually a good metric

[aepervius]

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.

Yes C is dying

[Anonymous Coward]

All the new programmers should go learn $HOT_SHIT_LANGUAGE and leave C alone. This will help ensure that those that actually know C well will always have a job.

Re:Yes C is dying

[Proudrooster]

If I had mod points, you would get them ALL! Yes, go learn Python or Ruby on Rails or Visual Studio or Swift.

Re:Yes C is dying

[gweihir]

Hahaha, joke is on you! I use Python with embedded C modules for most things I do these days. Yes, if you are really skillful, you can have the best of both worlds.

Re:Yes C is dying

[Aighearach]

Luckily most of the youngsters learning C these days call it Arduino and they won't even know to compete for the jobs! ;)

Re:Submitter is clueless - 99.9% of web sites run

[JaredOfEuropa]

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 web development (just my personal list, I am sure there are many others). You can use C for both, but personally I don't know anyone who does. PS. I don't count the object-oriented variations of C as "C".

Bah... C is still king baby

[Proudrooster]

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.

Re:Bah... C is still king baby

[phantomfive]

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.

Re:Bah... C is still king baby

[EmperorOfCanada]

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 I just walk away in the same way that I wouldn't buy a car made in Russia.

Inevitable decline in popularity...

[Harold Halloway]

...since D was released.

Re:Inevitable decline in popularity...

[__aaclcg7560]

There's F# if you want to take your mojo up to 11.

https://en.wikipedia.org/wiki/F_Sharp_(programming_language)

Re:The Internet of Shit depends on C

[Half-pint HAL]

Well, the whole Internet of Shit depends on C programmed Linux enabled ARM processors, so one could wish for it to be dying, but it is very unlikely.

Are we sure that's true? These Linux-enabled ARM processors are more powerful than the PC I was programming in interpreted languages at the turn of the century, and most of them are doing very simple things like turning heaters or lights on and off, which isn't computationally expensive. Small indy "things" are often built around the Raspberry Pi, because that's what the prototype was built on... and probably in Python. If I was building a garage door opener out of a computer with enough grunt to run four simultaneous games of Quake, I don't think I'd really care about optimising my code to that extent.

C is only dying in the buzz department

[JoeyRox]

C is not the next great thing. But is still the one of the best things and will always be a workhorse.

Re:C is only dying in the buzz department

[gweihir]

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

Re:C is only dying in the buzz department

[Aighearach]

The buzzy parts got renamed "Arduino."

Re:We're all programming in Machine Code

[JoeMerchant]

This statistic might just mirror my thinking on the "popularity" of C. Are we talking market share, or number of users?

I'd guess that the number of users is remaining constant, or slowly growing. The market for users of programming languages continues to expand rather quickly, so it's entirely possible that C's market share declines while its number of users continues to grow.

Then you have the college grad resume effect: every language they ever wrote two lines of code in ends up on the resume... what does lines of code mean, anyway? Can we have a metric for number of hours that end-users execute code that was written in each language, coupled with another metric for number of hours that people spend writing and maintaining that code? Is there any way to untangle that from the number of hours spent in requirements gathering sessions and showing prototypes to people who don't know what they want? I don't think so.

Re:Delphi #11's written in Object Pascal

[JoeMerchant]

Calling out MSVC as the reference C compiler for execution speed is like calling out a parade float as the performance reference for internal combustion powered vehicles.

It depends

[hackwrench]

It depends. Are we talking in absolute terms or per capita. C is still the best tool for the things it has always been used for but as programming becomes more mainstream, the percentage of people who are interested in such tasks is going to shrink.

C is for mission critical software

[funky_vibes]

C is for mission critical software. Most other compilers, even C++, are too big to be verified properly.
The demand for things that don't randomly crash has gone down, we take bugs for granted now, therefore C naturally loses popularity in favour of languages that don't take coding so seriously.

C is slowly being replaced by C++

[cpghost]

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.

Re:C is slowly being replaced by C++

[Dutch Gun]

The real problem with C++ is not slowness, but being too complex and unpredictable. I think that what will happen is that C will get the few good features from C++, and the rest will die.

You're correct that C++ is typically no slower than C, but it seems very unlikely to disappear anytime soon. There are probably billions of lines of C++ out in the real world. It will never be the most popular language, but it's a very significant one, and will be for quite some time. C++ is used when you need the performance of a to-the-metal compiled language like C, but need better abstraction models for large, complex systems. But unlike some other languages, you typically pay little to nothing extra for these abstractions, as the burden is shifted to the compiler. There are many times when performance really does matter, and you can't simply afford to throw more hardware at a problem, such as a very complex application on a single client PC, a videogame console, or at massive scales like in mega data centers.

If you think C++ is "unpredictable" then you just don't know the language all that well. I'm not trying to sound arrogant or condescending, as it's absolutely a difficult language to learn and especially difficult to master (hell, probably near impossible to master it *all*), but "unpredictable" is how you describe managed memory, not C++. Yes, C++ has a lot of sharp edges as a language. It's ugly, clunky, bloated (aka "feature-rich"), slow to compile, and difficult to master. But it also has a large, mature ecosystem (thanks to its C-based heritage), and damn near every significant CPU or platform has a C++ compiler that supports it, probably topped only by C.

So really, it's reasonably safe to say that neither C nor C++ are going anywhere anytime soon, thanks partially due to sheer inertia caused their pervasiveness through our critical infrastructure. This fact alone dictates that compiler support will remain a priority among major software companies (Microsoft, Intel, Apple) or projects (Clang, CGG). Add to that the enormous codebases that companies have invested in with both languages, and C/C++'s longevity is even more likely.

Re:C is slowly being replaced by C++

[gweihir]

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.

Re:C is slowly being replaced by C++

[Tablizer]

It seems there are insufficient alternatives around: Something that runs close to the metal, scales up to larger code-bases abstraction-wise, yet has enough high-level protections to avoid easily shooting yourself in the foot through bad pointers or bad type conversions that get past the compiler.

One probably wants access to the "guts" when actually needed, but otherwise that access is not the default. One has to explicitly tell the compiler, "Yes, I really want to do risky low-level stuff in this block. Please allow".

Re:We're all programming in Machine Code

[truedfx]

Nobody was talking about either pre-2000 compilers or about C++ compilers, let alone pre-2000 C++ compilers, so whether those were written in assembly, C, C++, or even Fortran or any other language is not relevant.

Re:We're all programming in Machine Code

[MobyDisk]

It is modded-up because it is both correct, and insightful.

...so C++ is technically written in C...

No, it is not "technically written in C." At best you could say "in the past it was written in C." But that statement applies to almost everything, and misses the key point. The key point is that compiler writers have moved from C to C++, even for writing C compilers. That is an important indicator of C's popularity and future.

Re:We're all programming in Machine Code

[hey!]

C was conceived as a portable shorthand for assembly language. It has evolved into its own beast over the decades - especially when you include C++.

It makes no sense to include C++, just because C++ shares certain elements with C. The design philosophy is completely different. C is a minimalist language. It has acquired more features over the years, like unicode support, but based on demonstrable need. C++ is more prescriptive in its philosophy: these are the features you should be using if you want to be doing object oriented programming.

Re:We're all programming in Machine Code

[JoeMerchant]

The fun thing about C++ is that you can write virtually straight C in it (or, port existing C into it) and it works, well - with tiny adjustments here and there.

Re:Submitter is clueless - 99.9% of web sites run

[Anonymous Coward]

Websites and mobile apps aren't written in C. That the routers use C or the web server might be written in C is irrelevant - when you're writing a web or mobile app, you are interacting with those devices via HTTP, maybe TCP/IP, etc. If you're using library that's written in C, you're using the API bindings for the language you're using. Why would you be thinking of C? Its like arguing that someone who uses Microsoft Excel would be thinking of C because parts of the Windows kernel and Excel itself are written in C.

Re:We're all programming in Machine Code

[glenebob]

I would imagine assemblers are written in C++ as well. Why not?

As with all headlines that pose a question...

[Notabadguy]

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.

Re:As with all headlines that pose a question...

[Mybrid]

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 used web platform languages. Again, not the syntax, the PHP interpreter.

Those or the pertinent discussions. Popularity is for pop culture, not engineering.

Jobs ads always seem to ask for C/C++

[walterbyrd]

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

Re:We're all programming in Machine Code

[Highdude702]

Thank you! Im rather new here compared to you.. but in the 10 years or so ive been coming to this site. ive never seen it as bad as it is now. This is a ludacris post. To even fathom that C will die...

Re: programming tosh

[golodh]

@Big Hairy Ian

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

Rubbish.

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 dealing with a water-cooled internal combustion engine, a gearbox, a drivetrain, the suspension, brake disks, a chassis and a set of wheels.

You'd never get anywhere if you tried. Same with assembler, let alone machine code.

Re:We're all programming in Machine Code

[slashdice]

It should be, but there are people who insist on talking about the "C Machine" and "undefined behavior". Unfortunately, most of them are compiler writers and ignore that your code is going to run on an actual computer with actual defined behavior. Result: the compiler goes full retard and "optimizes" away code because somewhere there might be a computer that doesn't use two's complement integers.

I'm calling Betteridge on this one

[tietokone-olmi]

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

Re:We're all programming in Machine Code

[__aaclcg7560]

I would imagine assemblers are written in C++ as well. Why not?

I'm working my way through an old book to create a Pascal compiler in C. I went with the C edition since it was easier to translate the MS-DOS era code into a modern variant of C than the C++ edition. I'm also learning C to write Python C extensions. Once I'm done with the book, I'll get back to my BASIC compiler in Python.

More to the world than the Web

[PPH]

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.

Re: We're all programming in Machine Code

[Anonymous Coward]

It's worse than that. Since they base this on Internet searches, which is a metric only an idiot could think is good, you end up in a situation where dumbed down languages used by dumbed down people who are too stupid to even use those without handholding pump up search volume for those very same languages.

Re:Delphi #11's written in Object Pascal

[geoskd]

Calling out MSVC as the reference C compiler for execution speed is like calling out a parade float as the performance reference for internal combustion powered vehicles.

It works just fine, and is taylored to people who like to see large numbers in their benchmarks: "This compiler over here has a performance rating of 72 MSVCs, this other one has a rating of 104 MSVCs, and then there is clang with a whopping 463 MSVCs."

It works for me...

64bit asm OS

[GlowingCat]

Latest MenuetOS videos: https://www.youtube.com/channe...

Re:We're all programming in Machine Code

[hey!]

I'm well aware of this, but it doesn't change the fact that C++ is a different language with a fundamentally different philosophy. Adding features to a language is not some kind of neutral operation; it can affect users that have no intention of using those features.

Were it not for operation overloading the argument that C++ is simply C with classes would be a lot stronger. Then if you came across the expression "a + b", you would know it means exactly what "a + b" means in C: either integer addition, floating point addition, possibly with an implicit typecast on one of the operands. In C++ the "+" might be something else altogether; it might even have side effects.

This is neither good nor bad, but it's unquestionably different.

Oh, and by the way, moderators: troll? Really?

Re:We're all programming in Machine Code

[dargaud]

This is neither good nor bad, but it's unquestionably different.

I beg to differ: it IS bad. Because when you read a+b, you have NO idea what may be happening. And this applies to ALL the operators. And the effect of the overloading can be completely different for various types. If participating in the underhanded C contest is not too hard, there's no need for an underhanded C++ contest because it'd be beating a dead horse.

Re:We're all programming in Machine Code

[hey!]

I see it as a mixed bag. If you are extending the addition operation to non-built-in types like matrices or complex numbers it's a good thing, although you can obviously screw it up. If you're implementing some kind of Abelian group or algebraic ring it's a good thing. Even if you're just using operator overloading in some way that makes intuitive sense, like string concatenation ("a" + "b" == "ab") or repetition ("a" * 3 == "aaa") or comparison ("a" "b" == true), I see it as a good thing.

But operator overloading obviously gives a great deal of scope for sloppiness and obscurity.

Alt: "C doesn't require as much study as others"

[Ungrounded Lightning]

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

"The ordinary documentation of C is clear enough that web searches are rarely needed."

and so on.

This doesn't mean that C use ISN'T declining. But it does mean that additional measures using different metrics would be required to determine that this result isn't just an artifact of the methodology.

Re:We're all programming in Machine Code

[serviscope_minor]

Adding features to a language is not some kind of neutral operation; it can affect users that have no intention of using those features.

Having had to debug someone's FORTRAN code which just happened to be written in C++[1] I can assure you that some people are quite impervious to language features.

[1] It's the old quote, you can write FORTRAN in any language. Old school numerics types of any age do this.

Re:We're all programming in Machine Code

[serviscope_minor]

I beg to differ: it IS bad. Because when you read a+b, you have NO idea what may be happening

I beg to differ with you!

If you see the function add(a, b), you have NO idea what may be happening. And this applies to ALL the functions. In C++ a+b simply means operator+(a,b) IOW it's a function with a funny syntax just like any other.

And the effect of the overloading can be completely different for various types.

Well of course, adding two floating point numbers is a very different operation to adding two integers. Totally different instructions. The former can even generate a floating point exception and crash your code if you've set the exception flags. And then there's adding two signed inegers. You can always safely add unsigned types. If you add signed ones, overflow invokes nasal demons.

some stats

[buddyglass]

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

C is not dying and I wish it would.

[Larsen E Whipsnade]

C is responsible for the vast majority of stray pointer and buffer overrun vulnerabilities. Together with SQL injection and macros, it's making computing unsafe. C++ ameliorates the problem but does not eliminate it.

C/C++ are low-level languages used to implement everything else. There is no direct replacement. We desperately need one. What's the holdup, folks?

I had a look at Rust and could only ask: why isn't this twenty years further along by now? Oh, and... what's with that huge embedded runtime?

Re:C is not dying and I wish it would.

[gweihir]

C is responsible for the vast majority of stray pointer and buffer overrun vulnerabilities. Together with SQL injection and macros, it's making computing unsafe. C++ ameliorates the problem but does not eliminate it.

That is unmitigated bullshit. The language is not the reason for these problems, the coders are. Only a completely clueless person would blame a hammer for its ability to break things.

C/C++ are low-level languages used to implement everything else. There is no direct replacement. We desperately need one. What's the holdup, folks?

There is no "holdup". It cannot be done any other way. Either you have the power of C and then you also have the destructive power, or you don't, and then you cannot do the things C can do.

I had a look at Rust and could only ask: why isn't this twenty years further along by now? Oh, and... what's with that huge embedded runtime?

Simple: Rust is far less useful than its proponents claim. When you actually need its full power, you have to go to an "unsafe" model, and then it is about a save as C. Hence rather invest in learning C well, than going to a tool where you usually have a safety-net, but when you need to do without you do not have the experience to do so. The whole model is flawed fundamentally. It is not the tool, it is who wields it.

Re:C is not dying and I wish it would.

[Actually, I do RTFA]

Having the compiler check my work 90% of the time would still be nice. But, more importantly, if I know I don't have to check my jr. programmer's work for stray pointers outside an unsafe block, I can spend more time focusing on more useful input. And I can work with them on what the unsafe block should do and how to deal with things in it safely.

I like it when the compiler makes it easy to catch my errors. That's why, for example, I like matching curly braces (detect an error) over the intelligent whitespace in Python. And static typing over dynamic typing.

"popularity" is irrelevant

[gweihir]

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.

Re:Is your mum declining in popularity?

[yuvcifjt]

@Mods: Whichever idiot(s) modded the parent as "interesting" needs to be banned / moderator-rights taken away - they clearly don't have a rational mind, especially considering the subject of the post!

Certain languages attract assholes

[EmperorOfCanada]

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 of the worst of the worst, PHP framework evangelists. That portion of the PHP language world attracts assholes like black holes attract light.

So while many of the comments here mention the technical virtues of this or that language, I find that culture is something that can make or break a language. For instance C++ is just now getting over the hump that was the pile of assholes who wanted to template the shit out of everything. I am literally talking about people who thought was rational that ints be turned into objects and never use the "primitive" datatypes. That whole generation of assholes must have been hunted down and boiled in acid as they seemed to have largely vanished from popular C++ culture. Hence C++ is now having a resurgence with their vanishing.

Re:Certain languages attract assholes

[Tranzistors]

CSS programmer (are they seriously claiming to be programmers)

If you believe that writing vanilla SQL is programming, then so is writing CSS. Both are just declarations of desired outcome and it is up to the interpreter to get there. Even functional programming is like that.

Re:Certain languages attract assholes

[EmperorOfCanada]

I don't.

Re:We're all programming in Machine Code

[Aighearach]

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.

Re: programming tosh

[Aighearach]

No?

Yes.

Re:We're all programming in Machine Code

[JoeMerchant]

Power corrupts - especially in computer software. The most powerful languages and programs are the easiest for the users to become utterly lost and confused in. Nobody had a problem when the computer was a single switch between a power source and a light-bulb - On/Off, even your dog can figure that one out after a while. Take it up a notch with a second switch in another location and people start getting confused - especially if some joker puts the distant switch neither in up or down position, but in the middle...

Just because C++ has the power to do amazingly complex things does not mean that doing amazingly complex things is always (or even often) a good idea.

Re:We're all programming in Machine Code

[JoeMerchant]

Watch out for the nasal demons... they're perilously close to your optic nerves.

Re:Submitter is clueless - 99.9% of web sites run

[Aighearach]

I write mobile apps in C you insensitive clod!

Line between C and C++ blurred ...

[perpenso]

I'm well aware of this, but it doesn't change the fact that C++ is a different language with a fundamentally different philosophy. Adding features to a language is not some kind of neutral operation; it can affect users that have no intention of using those features.

The point you are missing is that you don't have to use most of those features, and sometimes you should not. If someone want to write a project in "C" they will probably use a C++ compiler and use a minor feature of C++ or two. Their resulting code being far closer to C design and philosophy than C++'s. People have been doing so since the 90s. So the lines are quite blurred and the original question poorly thought out.

Re:Line between C and C++ blurred ...

[hey!]

The point you are missing is that you have to maintain other peoples' code.

Re:Line between C and C++ blurred ...

[perpenso]

Actually I've started projects and inherited projects that used the hybrid approach. The goal, back in the day, was to "enhance" C with a little bit of C++. The coding style and approach was still essentially C. The notion that using C++ requires a full blown OO approach and use of many advanced features is mistaken.

Re:Line between C and C++ blurred ...

[hey!]

You need to understand operator overloading, even if you don't use it.

Re:Line between C and C++ blurred ...

[perpenso]

You need to understand whatever bit of C++ you are using to "enhance" C. Plus operator overloading doesn't require that you shift from a C design and philosophy approach. I used operator overloading in a decimal math library, its fairly K&R looking code. The user defined decimal number type doing what one would expect with mathematical operators.

Re:Line between C and C++ blurred ...

[hey!]

Well, any professional programmer should understand the concept of operator overloading; however my problem with the way you're framing the problem is that you're assuming an individual programmer has a choice about the features of the language he has to deal with. If you're a lone wolf, sure. But most of us have to maintain code other people create.

Re:Line between C and C++ blurred ...

[perpenso]

As I said earlier I've inherited and ported many a project that used the hybrid approach I discussed. Over the decades C++ has often been used in a "lightweight" manner with a very "C like" approach.

Re:The Internet of Shit depends on C

[Aighearach]

traditional embedded devices that are DRVs and similar types of boxes generally had linux, but with IoT it is more normal to forgo even having an OS, or using something really lightweight like FreeRTOS. Even the proprietary SDKs are generally built on top of FreeRTOS or similar.

No surprise that you blame a category of things for whatever your beef is, and also don't know the details.

Re:We're all programming in Machine Code

[djrobxx]

I beg to differ: it IS bad. Because when you read a+b, you have NO idea what may be happening

I beg to differ with you!

If you see the function add(a, b), you have NO idea what may be happening. And this applies to ALL the functions. In C++ a+b simply means operator+ IOW it's a function with a funny syntax just like any other.

Not true. In C, if I see "a+b", I generally know that I'm getting the time-tested and well understood behavior of the compiler adding two numbers together. If I see "add(a,b)", I know that something more complex may be happening, and that if I need to know more, I should go look up the source or documentation for the add(x, y) function.

I understand the potential readability benefit of operator overloading, but I've never liked the cost of making known compiler behavior ambiguous.

Online C code examples are dying...

[nedgofast]

I used to search for examples of C-code online with quite a bit of success. However, over the past two years I've found that the search engines just don't find the C code examples like they used to. Google search is no longer my "go-to" tool for trying to find code snippets. I search through other codes that I've worked on or written in the past. I supposed the development of good help features in IDEs has played a major role.

Obligatory link to Stroustrup "interview"

[Latent Heat]

http://harmful.cat-v.org/softw...

Blame the coders! Great!

[Larsen E Whipsnade]

All we have to do then is fix the coders and all our problems will be solved!

Wait. How do we fix the coders?

It's a poor manager who blames his coders.

Re:Blame the coders! Great!

[gweihir]

It is a poor manager who hires incompetent coders in the first place and it is a poor coder who is incompetent.

You do not "fix" coders. You let those that can do it well do their thing and tell the other to stay the hell away from it. Poor coders have negative productivity and there are a lot of them around. That needs to stop.

Design philosophy is different...

[Larsen E Whipsnade]

in ways that don't really address the deficiencies of C very well.

Oh, and it's got lots of new bad ideas.

Sometimes assholes have a point.

[Larsen E Whipsnade]

If you do it wrong in C - or assembly- it's really, disastrously wrong. And it's wrong in a way you don't realize until years too late.

But really, that's a defect in C. And in humans, that we're not all capable of coding flawlessly. Which side of the problem is easier to fix? Oh... false dichotomy. Perverse human nature prevents us from addressing the issue with our tools!

It's a poor workman who chooses bad tools. Or a PHB who chooses for him.

C was a great innovation for its day, but it has lasted far longer than it had any business lasting. Likewise Perl. Likewise SQL. Language design is mostly churn and not enough progress. They're not working the problems. That denies us something good to move on to.

Safe pointers, smart pointers, ditching the preprocessor - if I'd had oodles of free time I'd have done everything Rust attempts years ago. It seemed self evident to me that long ago, but the people who actually have the free time waste that free time inventing stuff like PHP.

Or maybe PHP and the like are just easier to invent. It does seem that not all that much effort was put in.

It can't happen soon enough!

[Tony Isaac]

And can we PLEASE finally say good-bye to COBOL???

Blame the managers! Great!

[Larsen E Whipsnade]

Now... how do we fix the managers?

I have a feeling if we ever get rid of the stupid managers, the ones they're replaced with will have us avoid using C, and restrict to a subset of C++. Because an intelligent manager understands risk management.

I know a COBOL programmer.

[Larsen E Whipsnade]

He derives no sense of meaning or purpose from his work. It rather depresses him. But hey, it's a living. And he'll never, ever get laid off and forced to train some guy from Bangalore.

Easier? Don't you mean harder?

[Larsen E Whipsnade]

Operator overloading and templates obfuscate and much as that damn preprocessor.

Maybe templates are worth it. They bring significant added value. But they do make code hard to follow sometimes.

Multiple inheritance is a nightmare.

Re: We're all programming in Machine Code

[cyberthanasis12]

Maybe you should try modern features of fortran2008, it is clearer than C++. It may even help you write better C++ code. On a side note, how is auto much better than implicit declaration of variables of the 60s where you knew that a variable starting with j was integer?

If things broke very fast, that would be fine.

[Larsen E Whipsnade]

The problems would get spotted and fixed very fast. But the real mischief is when they break so subtly you don't realize it until many years too late. This is what C is prone to, because of those horrid pointers. This is why C sucks.

Unchecked pointers are bad, mmmkay? Don't make excuses for a bad tool. A good workman chooses a better tool. Unless he's prevented from doing so by apologists for bad tools.

And the gaslighting only adds insult to injury. Seriously. Fuck that whole way of thinking. A bad manager chooses bad tools, and then blames the coders. Life is too short for that shit.

The one virtue of assembly is that only the bare minimum is written in assembly nowadays. That minimizes the risk. I once had a boss wanted a whole suite of apps written in assembly because it would run faster. He would not listen to common sense. What an asshole. Went out of business after I quit. I don't miss him.

Now his spiritual heirs are telling us to write the whole damn suite of apps in C/C++. And the apps are bigger these days.

Re:We're all programming in Machine Code

[serviscope_minor]

I know that something more complex may be happening, and that if I need to know more, I should go look up the source or documentation for the add(x, y) function.

Well, in C++ you know something more complex is happening, so you need to look up the documentation of foo, add or operator+.

I understand the potential readability benefit of operator overloading, but I've never liked the cost of making known compiler behavior ambiguous.

The compiler behaviour isn't ambiguous, any more than it is for add().

Popularity? Who cares?

[jandersen]

I don't think the popularity is all that interesting; it is much more worthwhile to look at the usefulness of a language for the job at hand. For numerical programming, FORTRAN has always had a huge following, simply because it was and still is very good for that purpose. Same goes for COBOL and the handling of administrative datayou wouldn't write a compiler or a weather model in COBOL, but then you probably wouldn't want to write payroll application in FORTRAN, lisp, C or similar; you could, but it wouldn't make a lot of sense if you already have most of your codebase in COBOL. And so on.

C is still one of the best, general-purpose languages there are: the syntax is simple, yet it allows the programmer to easily use nearly any facility available in the HW. Java has grown in importance because the applications that are needed now are different: optimisation for speed and/or size is no longer a major issue, but portability is; also, the Java environment has implemented a very comprehensive set of standards for things like database trnasactions (JPA), security (JAAS) and just about anything else you need in browser based enterprise applications, which means you don't have to speculate about how to do this or which libraries suit your purpose best. You just follow the standards, and that is hugely attractive. Some day we won't need to develop so many new things in that environment, and Java will become less popular.

Re:We're all programming in Machine Code

[Wootery]

C is written in machine code

Nope. Maybe the earliest C compilers were, but all modern C compilers are written in C/C++.

Re:We're all programming in Machine Code

[jeremyp]

No it wasn't. C is a high level language and always was. You can argue that it was conceived to replace assembly, but that does not mean it is assembly in any sense.

Re:If you want performance

[Half-pint HAL]

How important is performance on telling a light-bulb to switch on and off though? Timers for thermostats don't need even to-the-second response times, never mind microsecond accuracy. Traditional embedded devices need tight monitoring cycles, but "things" are generally pretty dumb devices all told.

Re:We're all programming in Machine Code

[Wootery]

A fair point. A bit like this programming language is slow, which might be broadly true in practice, but is really a property of existing implementations rather than the language.