Slashdot Mirror
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?
Si.
Relevant C
2B || !2B
Either learn what you're doing
Or stick to the Wii
Burma Shave
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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'.
C is the high-level language there. If you want actual control over your target, you'll need to use assembly.
Is there another OS/system programming language that is universally accepted as a reference, rather simple to learn, available on virtually any OS, real fast? I mean, go is nice and multi platform and powerful, but it is not even close to C popularity.
C++ should have been C successor, but it is too complex to be.
It's like when you drunk drive and think you're just fine.
Well the problem there is you're drunk, not that you can drive. C is a great language, and it gives its programmers a great deal of power and flexibility. But with that comes responsibility not to code like an idiot. If you're going to wield its power carelessly, of course you're a danger.
Perhaps C's greatest weakness is that it places too much trust in the coder, where other languages don't.
If its too dangerous for humans, who do you think is going to write all the compiler/interpreter and low level OS interfaces of whatever alternative language of your choice is? At some point someone has to get their hands dirty down at the metal whether its in C or assembler. If you're not up to that then fine, but please spare us the poor workman blaming his tools excuse.
If you write a good useful library in C, it can be used from almost any other language, with little effort. If you write your library in any other language, you limit its use to a handful of related languages. Also, properly written C can be very portable to a wide variety of systems.
In Murphy We Turst
The main good reasons is the small footprint. I was recently given an ARM Cortex M3 prototyping board to play with. This is a pretty high-end part by IoT standards, but has 128KB of RAM and 512KB of flash for code and data storage. It's programmed using C++, but unless you stick to a very restrictive subset of C++ that's almost C, then you'll end up generating too much code (C++ templates are not just a good way of blowing away your i-cache on high-end systems, they're also a good way of blowing away your total code storage on embedded chips).
The other good reason is that it makes it relatively easy to have fine control. Not quite as easy as you'd want. To give one example, the JavaScriptCore interpreter and baseline JIT were rewritten from C++ into macro assembler a couple of years back because C and C++ don't give you fine-grained control over stack layout. To give another example, some game devs were recently complaining on the LLVM list that their hand-optimised memcpy implementations were being turned into memcpy library calls, because they assume that they're using a macro assembler when they write C, and not a language with a complex optimising compiler behind it. It does, however, give you flow control primitives that make it easy to reason about performance and fine-grained control over memory layout. These are particularly valuable in certain contexts, for example when implementing higher-level languages.
The biggest bad reason for C being popular is that we've standardised on C as the way of defining library APIs in UNIX-land. There's no IDL that describes higher-level concepts, there are just C headers, and the language that makes it easiest to use C libraries wins. There has been some improvement in C-calling FFIs recently, and a big part of the popularity of Python is the ease with which you can use C/C++ libraries from it. Even simple things are hard when interoperating with C. It's hard for an FFI generator to know whether that char * parameter is a null-terminated string or a pointer to an arbitrary block of memory that's going to be read by the callee, a pointer to a single char that's going to be written back, or whether the callee returns a pointer to within the block and needs the original memory to persist. Lots of libraries take function pointers that have a void* context pointer, so can be mapped to closures in the caller's language, but they all put the context object in different places so you need a custom trampoline for each one.
With over 8 billion lines of open source C code (source: OpenHub.net), there's a good chance that the library that you want to use is written in C.
I am TheRaven on Soylent News
I was and still am a pretty accomplished C prorammer, and can find my way in assembly. Then C++ came along and everybody seemed to jump on that bandwagon. I couldn't and many of my collegues either. When you have progressed to far along the procedural path, it seems to be impossible to wrap your head around the object oriented paradigma. That is why I also never got into Java.
Paai
You need to progress through modular programming and abstract data types. Then OO makes a lot of sense. Well written, highly modular C code with good abstractions tends to resemble well-written C++ without operator overloading in my experience.
Hell, well-written modular programming resembles well-written OO programming (since the later can be seen as a natural extension... or conclusion of the former.) Well-written procedural code must exhibit characteristics of modular programming.
What happens with C++ (specially at the beginning of its development) is that everybody tended to use every single goddamend feature, abusing operator overloading (and later templates). So C++ became "equivalent" to "overloading gotcha and magic-behind-the-curtains" soup smeared over a tangle of classes in an inheritance tree from hell (in many ways, not dissimilar from Java at the beginning with its own gotchas.).
One can program clean C++ with very simple semantics, using operators to the bare minimum, using templates judiciously, knowing when to use virtual and always implementing the big three (default constructor, copy constructor and = operator.)
If you can modularize your procedural code and how to layer your abstractions, then you know how to split your code into modules and classes. You know how to encapsulate and delegate responsibilities. That is key for developing cleanly in C++ (or Java or C#... or in any language for that matter.)
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.
We're talking about C. You want the zeroeth post.
I would argue that it is better to learn to write decent code than to let the language protect you from the effects of bad code.
I would argue that there is a middle ground. C++ still lets you do the low level stuff when you need to but also provides higher level structures that when used responsiblly make code clearer and less error prone.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I have written embedded Pascal. Never ask me to do it again.
. As a long time C hack (still am) I concur.
Behold. A C program that has gained sentience.
" don't really seem to understand the difference between pointers and C arrays"
Well, because there isn't one at the language level. The array syntax using square brackets is only a syntactic sugar for pointer arithmetic, nothing more.
There is a difference between an array and a pointer.
char a[100];
char* b;
b = a; // Fine // Not fine.
a = b;
If you read the standard, the language used is that, in an expression, an array "decays" to a pointer with the rule being that you get a pointer to the array's first element. The "array is not a pointer" rule is further demonstrated by passing an array to sizeof (as viol8 points out).
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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."
We're talking about C. You want the zeroeth post.
You have to remember, there are two kinds of people in the world:
1) Those who begin their indexes at 1.
-and-
1) Those who begin their indexes at 0.
C is not a tool for the incompetent (whether temporary due to alcohol or permanently). It is an expert-only tool. There are a few of those around and they will stay around, because in the hands of somebody skilled, these tools deliver exceptional results that no more generally usable tool can match.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Actually this is false. It is possible to write a language that is both safe* and compiles itself.
If you're not up to that then fine, but please spare us the poor workman blaming his tools excuse
I can cut a straight line with a circular saw without using a guide or a guard, but I can do it a hell of a lot quicker with a guide to rest against and a guard to keep me from having to constantly check my fingers and chords etc. These things weren't invented because of bad workman, but because they make good workman better. Not everyone who notices that there may be better tools out there than C for the very things that C is used for is a workman blaming his tools.
Someone eventually needs to write the rules for translating the higher level language down to lower levels, but this isn't the same as "getting their hands dirty down to the metal" in the same way that you've implied because it can be done in tiny self-contained, small chunks following yet more rules and rigorously like a mathematical proof and therefore not be subject to the same pitfalls as languages like C. It also only has to be done once (per processor) but then the safety is ongoing.
This layering is just modular design and separation of concern. Look at IR in the LLVM project which has allowed an explosion of languages that can enjoy most of the same compiler optimizations that the C family enjoy using this principle.
(btw, the Rust project is very interesting in this subject)
* Of course, the term "safe" has a limited meaning. A compiler can't read your mind but, to the extent that a language is well designed, it can prevent you from doing things that you could not have intended to do and force you to follow rules that will never allow certain common errors that result from people having limited memory.
But C++ is a thousand times more than "C with objects".
I believe the above quote speaks for itself...
"C++, Objective-C, Perl, Python, Java, PHP, C#, D and Go all have block syntax that's derived from C"
And C got the block syntax from B which got it from BCPL which was a simplified version of CPL which was influnced by the first block structured language, ALGOL.
I was taugh ALGOL at University, though I had already been "mentally mutilated beyond hope of regeneration" by BASIC before that...
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".
No, no, no, you got the saying all wrong! Here's how it goes:
Or alternatively,
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
The downside of C++, is you can't look at the code and know what happens at the machine level. Joel Spolsky describes it below: (in an article on variable naming)
"In general, I have to admit that I’m a little bit scared of language features that hide things. When you see the code
i = j * 5;
in C you know, at least, that j is being multiplied by five and the results stored in i.
But if you see that same snippet of code in C++, you don’t know anything. Nothing. The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it. And i might be of a type that has operator= overloaded, and the types might not be compatible so an automatic type coercion function might end up being called. And the only way to find out is not only to check the type of the variables, but to find the code that implements that type, and God help you if there’s inheritance somewhere, because now you have to traipse all the way up the class hierarchy all by yourself trying to find where that code really is, and if there’s polymorphism somewhere, you’re really in trouble because it’s not enough to know what type i and j are declared, you have to know what type they are right now, which might involve inspecting an arbitrary amount of code and you can never really be sure if you’ve looked everywhere thanks to the halting problem (phew!).
When you see i=j*5 in C++ you are really on your own, bubby, and that, in my mind, reduces the ability to detect possible problems just by looking at code."
My opinion is, for code that lives closer to the OS (or the OS itself), where there are fewer lines of code but which run more frequently, C is king. For code that needs to multiply/grow/combine/evolve faster and still run fast, C++ is often a better choice.