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
C is the high-level language there. If you want actual control over your target, you'll need to use assembly.
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 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
We're talking about C. You want the zeroeth post.
and the people who do use C are not interested either since they tend not to be language fetishists.
This. Half of the newer high-level languages today are just the mental masturbations of someone who either thinks he can make the wheel more round or the result of a "not invented here" mindset. There's so much crap out there forking a perfectly good language because someone thinks it should be a =+ b; instead of a += b;
It's sickening, and a good reason to stay away from all this shit, because five years down the road someone will fork the fork and you can throw all your code away because support and development just stops as all the ADD kids jump at the new toy. That'll never happen with your C code.
Assorted stuff I do sometimes: Lemuria.org
. As a long time C hack (still am) I concur.
Behold. A C program that has gained sentience.
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.