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?
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.
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
To clarify: "Small target" means memory (RAM/Flash) is measured in kB, sometimes even in bytes.
You still have Python-capable processors for embedded systems if you can't afford to learn C.
As far as target size goes, that thing does not qualify as "small target".
FWIW, I've been struggling with LPC4300 series processors.
Those chips look like they're on the large end of "small target". Cortex-M4s are already pretty beefy CPUs.
The open source toolchain is just so bad that your CPU hard faults on first attempted function call (most likely due to incorrect memory maps).
You can usually get pretty detailed reasons for a hard fault if you dig into the appropriate CPU registers (HFSR, etc).
I'd check the linker command file. Setting up a basic memory map isn't that hard - it's the not-so-basic stuff where things get interesting (copying functions to RAM for execution, etc).
One of the big reasons C will probably not be going away any time soon is there is no replacement and not much work being done on one. The higher level languages, language designers are constantly trying to redo or replace, but there is not much interest in replacing such a low level language... and the people who do use C are not interested either since they tend not to be language fetishists.
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.
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.