C Programming Language 'Has Completed a Comeback' (infoworld.com)

InfoWorld reports that "the once-declining C language" has "completed a comeback" -- citing its rise to second place in the Tiobe Index of language popularity, the biggest rise of any language in 2017. An anonymous reader quotes their report: Although the language only grew 1.69 percentage points in its rating year over year in the January index, that was enough beat out runners-up Python (1.21 percent gain) and Erlang (0.98 percent gain). Just five months ago, C was at its lowest-ever rating, at 6.477 percent; this month, its rating is 11.07 percent, once again putting it in second place behind Java (14.215 percent) -- although Java dropped 3.05 percent compared to January 2017. C's revival is possibly being fueled by its popularity in manufacturing and industry, including the automotive market, Tiobe believes...

But promising languages such as Julia, Hack, Rust, and Kotlin were not able to reach the top 20 or even the top 30, Tiobe pointed out. "Becoming part of the top 10 or even the top 20 requires a large ecosystem of communities and evangelists including conferences," said Paul Jansen, Tiobe managing director and compiler of the index. "This is not something that can be developed in one year's time."
For 2017 Tiobe also reports that after Java and C, the most popular programming languages were C++, Python, C#, JavaScript, Visual Basic .Net, R, PHP, and Perl.

The rival Pypl Popularity of Programming Language index calculates that the most popular languages are Java, Python, PHP, JavaScript, C#, C++, C, R, Objective-C, and Swift.

Comments

Don't call it a comeback, it's been here for years

[JoeyRox]

C never went anywhere. Its mindshare was just continually eclipsed by whatever bullshit venture-captial-seeking-paradigm-of-the-month was en vogue for that month.

Re:C programs are too dangerous for net-connected

[iggymanz]

Nah, I'm guessing browser tech such as javascript and flash, mobile apps with embedded malware, and on the server side PHP the cause for entry.

And now we're seeing our hardware itself is deeply flawed...from mobile chips to desktop to server to mainframe.

Re:C programs are too dangerous for net-connected

[Travelsonic]

At some point, don't know where that is myself, one needs to look at programming practices as well, and not just the languages being used.

This really only indicates where jobs are now...

[StevenMaurer]

No one is seriously going to try to use C for front end web development, just as no one is seriously going to try to use Javascript in an embedded microprocessor. So what this study is doing is just pointing out where the current jobs are.

Trying to compare languages, is like asking "which is better? a band saw or a screw driver?". They're entirely different. And anyone who doesn't understand that, simply doesn't have enough experience with other programming tools yet.

The language stack is sorted out

[drolli]

I consider this the transition to a more stable period. For some time it was unclear how functions would be split between programming languages. All kind of ideas were in the room, with interesting new contenders. Still the programming community decided that the areas covered by Java, Javascript, C, Python are well distributed in the way in which they are and that "good enough is still good".

C# (competitor to C++ and Java in my eyes) seems to be dying. Swift doenst take over from objective C as fast as that one is going down. So for low-level languages nothing else is left. OOP and Data Architectures are firmly in the hand of Java, which has a very small overlap and a very good synergy with C. Python coesists in other areas, and hurts neither of he two languages.

So in some sense: the war is over and java, (C+C++), python, Javascript have won for now.

Re:Oh lord, that again?

[Travelsonic]

You're not suggesting that we make programs less efficient than possible because we have more resources, are you? IMO, while going nuts is not helpful, we shouldn't use resources inefficiently, or the like, "just because" we have the room - not only that, but not every programming project, career, involves software that has that sort of safety - embedded systems, for instance.

Re:C programs are too dangerous for net-connected

[arth1]

No bounds checking, no type checking. In 2018. Get serious.

A halfway good programmer doesn't need to trust the language to do that for him and is capable of ensuring boundaries. The problem is that halfway good programmers have become scarce, and today's coders are content to leave critical parts to a compiler they don't understand and black box libraries they don't know what do behind the scenes. So they need the handholding.

Don't call Tiobe a reliable metric

[Tough Love]

I'm not saying C did or did not come back, or did or did not go away. I am saying, you won't know from Tiobe, it way too random. They count language questions, not language usage, and don't make the slightest attempt to correct for predictable skew like selection bias due to who hangs out there as opposed to, say, stackoverflow.

My totally on reliable take on it? C dev population stays about the same: very few, very skilled, and very highly paid. Because of the latter, the number of C wannabes spikes from time to time, but don't worry, they will go away after they ask a few questions and still can't code.

Re:programming practices

[WaffleMonster]

But people are people, programmers are programmers, and there are bell curves of skill, care and attention, schedule reasonableness under which programs are created.

So let's not assume every programmer writing a potentially security-relevant piece of code is a really good, well educated in best practices, really safe designer and coder with enough time for testing and iteration. Assuming that would be naive.

It would be naive to assume general purpose language selection makes a meaningful difference with regards to security outcomes.

It's up to the architect to manage risk by selecting appropriate tools and methodologies to best address specific problem domain. Placing programmers in an environment that ensures failure by giving them the wrong tool for the job before them or where they are required to always be extra careful in order to avert disaster is extremely counterproductive.

So why not protect against common errors using the programming language constraints and checks? Most of these protections can be done with very little cost, performance wise or in loss of program expressive power.

It is not clear to me specifically what you believe is not being done that can be.

Compile time checks, static analysis, profilers, fuzzers and runtime bounds check code inserted automatically by compilers by default are generally available to programmers at little to no cost. Quite a lot of the old standard C library has over the years been marked as hazardous to your health by modern compilers.

We can teach drivers not to start the car engine with the car in "drive" because they might run someone over, or we can just design the car not to start except in park.

Obvious solutions to obvious problems already exist. Yet it does not follow obvious problems necessarily have tractable solutions. For example designing a car incapable of ever running anyone over is reasonably beyond current technology even though instances of reasonable measures to mitigate the problem exist.

One thing that has always fascinated me over the years is the lack of sufficient advances in outcomes commensurate with development and selection of new languages. Most instances of productivity gains and capabilities can be traced back to hard won incremental development of complex domain specific systems and hardware improvements rather than advancement of underlying general purpose language.

The fact virtually all system programming is still some flavor of C in my view speaks for the difference between hype, wishful thinking and reality. We've had decades and so far very little of substance to show for it.

Decade ago when processors that could execute java byte code natively were taped out I actually believed this would change. I assumed we would all be running java everything by now and this is from someone who personally never cared for the language.

Re:Oh lord, that again?

[angel'o'sphere]

Attitudes like this are why people need a computer 600,000 times faster with 262144 times the memory in order to load something just to check their e-mail. I don't use Rust. I use Go
Uh! You are hardcore!
I use a Mail.app

start all these projects in Python and Java that have no place being written in an interpreted language.
Care to point one out?
For most people doing programming at home Python e.g. is an excellent language.
And as you seem to live under a rock: Java is no longer interpreted, since u .. o ... 1995 or so?

C never lost its place, and won't for the foreseeable future. For system programming it's not just unparalleled, it's often just simply indispensable.
I guess you have a different idea what "system progaming" is than most people. System programming is not done in C since decades. You probably mean the remains of embedded programming where people are forced to use extremely small micro controllers for extremely simple tasks. The biggest "system programming" project that still is mostly done in C (instead of C++) is probably the linux kernel.

Computers are not people, they are electrical devices with bits and bytes, and sometimes you just need a language that embraces that rather than tries to hide it like its some dirty secret.
True. But exaggerated. So I allowed myself to emphasize "sometimes" by making it bold.
The last time I needed some bit fizzling in "Java" was when I wrote a SWEET16 emulator in Groovy. In other words: I work with Java since 1995 ... and more or less exclusively with Java (and other JVM languages) since roughly 2000. In that time I never was part of a commercial project where any line of code I wrote or glanced over needed a bit operation. With Java only having signed types, they are a pain in the ass anyway.

Re:C is still king, thank Engineering Schools

[Anonymous Coward]

If you learn Java or C++ you automatically have learned C

I knew some of those Java guys and saw their C. Their initial contracts generally expired without renewal and their projects were scheduled for a complete rewrite. There are worlds of difference between these languages and anyone going at C as if they were writing Java or Java as if they were writing C is going to cause a lot of pain.

Re:programming practices

[rgbatduke]

We can teach drivers not to start the car engine with the car in "drive" because they might run someone over, or we can just design the car not to start except in park.

We can also design cars to be incapable of driving faster than 30 miles per hour, because that is determined (by a committee of "experts", of course) to be the maximum "safe" speed that embraces 99% of all drivers on the road.

We'd all just pay for this safety. Pay in time. Pay in convenience. Pay in no longer having any possibility of "racing" a car or pushing the performance envelope for cars. Pay in no longer permitting anybody, anywhere, to design a car that does NOT have the speed governor built right in, and use all of the other crap that the CoE decided was necessary for even a raging drunk to be safe behind the wheel, including the car-surround baby bumpers and reinforced passenger compartment and feature that won't let the car start without all passengers wearing a kevlar vest and safety helmet.

This is an argument that is as old as time. If you like working with a fascist language that only permits you do allocate memory through an opaque interface that cheerfully trades off speed for an illusion of security, there are many to choose from. C, it is absolutely true, has comparatively few safety nets, although there are tools and techniques for making it as safe as you like. It is also true that it is difficult to write more efficient code than one can write in C short of coding in assembler, and C allows one to inline assembler for those cases where only assembler will let you access certain systems features (instead of waiting until the CoE decide that they are "safe"). Similarly, even good old Fortran has its place if you are doing massive linear algebra and want to optimize it for bleeding edge CPU features.

Could one modify C a lot more minimally, to make it safer than it is by nature while still not enforcing the OO kool-ade and outright prohibiting the use of malloc and pointers? Sure, probably -- some of the tools out there basically do that. But there are times when one can write code with malloc and pointers that is just plain magic compared to what one can get with OO opaque memory management.