How Relevant is C in 2014?
Nerval's Lobster writes: Many programming languages have come and gone since Dennis Ritchie devised C in 1972, and yet C has not only survived three major revisions, but continues to thrive. But aside from this incredible legacy, what keeps C atop the Tiobe Index? The number of jobs available for C programmers is not huge, and many of those also include C++ and Objective-C. On Reddit, the C community, while one of the ten most popular programming communities, is half the size of the C++ group. In a new column, David Bolton argues that C remains extremely relevant due to a number of factors including newer C compiler support, the Internet ("basically driven by C applications"), an immense amount of active software written in C that's still used, and its ease in learning. "Knowing C provides a handy insight into higher-level languages — C++, Objective-C, Perl, Python, Java, PHP, C#, D and Go all have block syntax that's derived from C." Do you agree?
Those widgets the clueless newspaper reporters and marketers call 'the internet of things', otherwise known as embedded systems, depends on Linux and C. So therefore C is 'the next big thing'.
With C you can be OO, but you can also be nearly ML. And you can do them at the same time.
Nearly lost my coffee... it is hard to figure out your point of view. If you use ML to mean machine language, and not the language ML, you must be quite old or quite young... if you think C is close to machine language, you can't be that old, but if you classify C as OO as anything more than in a rudimentary way, you can't be that young....
Because it's extremely dangerous and a lot of people are still using it. The 'standard' standard library is so full of security holes it's not even funny, and attempts to 'improve' it over the years have mostly been unsuccessful because the bad coding patterns still exist.
C is a great language, it's just that most humans are incapable of using it safely and securely. It's like a .45 with a downward-pointing barrel. It's all too easy to shoot yourself in the foot.
For full disclosure, I used to be an avid C programmer, until I realized the harm I was causing myself and others. It's like when you drunk drive and think you're just fine. It takes an external perspective to realize how reckless your behaviors are.
A fool and his hard drive are soon parted.
C++ is C
I used to believe in this until I had to work on both. Although one can compile best-practice C with a C++ compiler (sans the gotchas), that glosses over the idiosyncrasies of each language. C does not have initializers as in C++.
More importantly, it does not have references, type-safe casting operators and its template language is not turing complete as in C++. These differences will never go away, and these differences alter completely the type of design and implementation of your code and your abstractions.
Not to mention the C++ rules of PODs versus everything else which affect how we link C code with C++ code (and viceversa.) And modern C++ heavily uses templates in manner that makes the language resemble something else entirely. Whether that is a good thing is highly subjective, but whatever.
So from a practical point of view, it is sane to treat both languages as fundamentally different.
When we program in a language (be it Ruby, Java, C or C++ or whatever), we ought to do so in the idiomatic way that naturally exploits the best capabilities of the language. So with that in mind, we cannot treat C and C++ as the same language (and it is not quite accurate to compare modern C++ as a superset of the former, regardless of historical evolution.)
I do believe, however, that is very important, if not fundamental, to understand C semantics to use C++ effectively. The fundamental semantics behind the primitive types and control structures remain more or less the same. And I've always found that C++ programmers without a good background in C tend to make certain mistakes when they need to operate with pointers (since they are so used to work with references.)
Furthermore, integration of C with C++ is not an uncommon task, and development of C++ code with that in mind is paramount. It is very hard to do that without a good understanding of C.
To mobile application market? Irrelevant.
To online web services? Not so relevant.
To online web server? Very relevant!
To high efficiency applications? It's almost the standard.
To operating systems? There's almost nothing other than C (in terms of market share).
Please, elaborate more on your stupid question, you insensitive mobile clod!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
.. or at least people who think they are clever. Occasionally they are right.
I have written embedded Pascal. Never ask me to do it again.
Ok I will bite. Now I don't claim that C is on the same level than ASM, but you need to compare it to current languages. Languages like Python or JavaScript, they abstract out almost everything about the machine you are running them on. With C you program against a reasonably close abstraction of the real machine. In many cases you can hand compile the C code to ASM.
Take for example the JS expression $("a").addClass("blue"). This expression written in C would take up something around 100 lines of code, simply because the machine you program against does not understand high level concepts. Even simple concepts like a string are not understood by C.
I love programming in C, but in whole ecosystem of languages it is on the low end.
I have issues with that notion, though. There's this popular perception among hardcore C programmers that C++ is "C with objects", and since they don't like or don't feel the need to do object-oriented programming, it's pointless for them. But C++ is a thousand times more than "C with objects". And even when it comes to objects, the most important ones aren't the ones you make yourself, but STL. Especially with the latest versions of C++. I just recently had to downgrade a simple app from C++11 to C++03 to support old compilers, and my god, I had forgotten what a royal pain pthreads are versus std::thread with a lambda argument. And if I had been forced to go all the way down to C, and thus would lose the std::list that simplified holding the threads' arguments. It would have been a page or two of code for what's a single line in C++11. And with far greater proclivity for bugs.
I once was one of those "hardcore C programmers" who just saw C++ as "C with objects", and deliberately avoided using it and learning any more than I had to. But the more I learned, the more I came to appreciate it. I do of course make and use my own objects... but that's not really the most important aspect of the language. It's all of the countless features to automatically manage memory, data structures, ensure program correctness, and vastly reduce pointless verbosity that make C++ so important.
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
OOP is a style, not a language feature. Sure many languages make this easier to do, but writing OOP in C is certainly possible, as many of us can attest.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
The clever people use C when C is the right tool for the job and use something else when it isn't. The rest use C, Python, or whatever else their favourite language is, irrespective of whether it's the right tool.
I am TheRaven on Soylent News
C++ is no more complicated to use than C. You can write C code in C++ and it'll work just fine, with only a few rare exceptions.
What C++ does give you is many more capabilities. Now, if you don't want to take the time to learn these capabilities, that's not the language's fault. There's a few things that were implemented a bit awkwardly (mainly looking at you, streams), but the vast majority is quite simple and straightforward, and it just keeps getting better and better (check out the capabilities of C++11 if you haven't yet - auto declaration types, inline threading, for-each looping, smart pointers in STL, and on and on... really, really nice).
If you don't like a particular part of C++? Don't use it. But that's no excuse to use "C-only". Want to use printf instead of cout? Go right ahead. But dammit don't do your own memory management when you don't absolutely have to, or your bugs are going to screw over the rest of us when we use your software.
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
But C++ is a thousand times more than "C with objects".
I believe the above quote speaks for itself...
This may be true for new code, but when maintaining C++ code written by others, not so much. Everyone has a different set of "features they like".
Even if you mostly program in other languages eventually you need to interface with some system function or legacy library and you *will* need to use C.