Slashdot Mirror
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.
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.
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.
What changed? Did someone let slip that bitcoin mining can be done in C faster than with remote calls to jquery?
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.
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.
If you believe in privacy, and believe you have "nothing to hide" at the same time, you're a goddammed idiot
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.
Oh Lord, seriously? This again? C is more dangerous than Java the way that a KA-Bar is more dangerous than a butter knife. If you take a real programming language, hamstring it, put a bib on it, and pull its teeth so it can process nothing more than strained baby food, sure, it won't be dangerous but then again it won't do much useful either.
Write a device driver in Java or Python. Or a kernel. C will always have a place in net-connected computers. You just don't hand a loaded gun to a child and expect he'll produce something useful without blowing his foot off. C is for grown-ups and when you get big and strong and if you eat all your spinach maybe when you grow up you'll do system programming too. Until then, feel free to play around with interpreted languages that pen you in a coral so you don't do anything stupid and feel free to pretend that JIT really does mean it's compiled and just as fast as native code.
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.
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.
If you believe in privacy, and believe you have "nothing to hide" at the same time, you're a goddammed idiot
Everything on planet freaking earth has firmware in it now and guess what compiler makes the smallest binaries that can talk to hardware?
Yes, that's right C.
Python can talk to C, but you aren't going to write firmware or low level interrupt handling code (like reading IR pulses) or monitoring an I2C bus.
Java is C's fat lazy son that lives in the basement and consumes all available resources can do things eventually, if you give him enough resources, time, and be able to tolerate the odor.
As long as computer architecture remains constant, C will be king. It's fast, small, and get's sh*t done now. Plus once you write it in C, you can call it from any other modern programming language like Python, Java, Objective-C, Swift, etc ...
I went to a graduation party of a graduating Aerospace engineer last weekend and his advice was learn C, learn simulation and solving software like Mathematica, learn how to work in teams, and be multidiscipline in career focus for great success. He graduated from Perdue.
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.
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 when I must. It's not a bad language as new languages go - Syncthing, a project I've contributed to, uses Go and it's not terrible.
In a way you're correct. I'd agree that only about 10% of software really needs the performance and versatility of C. Most others can get away with C++, for better organization, or some other natively compiled code. Go if you like. Or Pascal if you want something old school but still strongly type checked. I actually use Pascal quite a bit myself, simply because of the free Lazarus environment. Even interpreted stuff has its place, but far less than it is used for. Just as only about 10% of software needs the power and versatility of C, only about 10% of software is appropriate for an interpreted environment. The problem is, kids coming out of school high on what some unfortunate profs (who often don't have to work in the real world) have been feeding them then start all these projects in Python and Java that have no place being written in an interpreted language. Python is good for small front ends. But then someone will want to get fancy and use PyGTK or some other frankenlibrary or else what started as a little front end simply grows beyond what is really appropriate and it becomes non-portable and a nightmare fast.
I actually have nothing against any language. I have serious problems when they are used inappropriately, though, and I have even more serious problems when what has been the best swiss army knife programmers have ever had for the better part of half a century is slagged in favour of some du jour. 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. 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.
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.
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.
Even when the experts all agree, they may well be mistaken. --- Bertrand Russell.