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?

Comments

Si.

[Anonymous Coward]

Si.

Relevant C

[smittyoneeach]

Relevant C
2B || !2B
Either learn what you're doing
Or stick to the Wii
Burma Shave

Re:Relevant C

[BarbaraHudson]

To "C" or not to "C", that is the question.
Whether ’tis nobler in the mind to suffer
The slings and arrows of java coders,
Or to take arms against a sea of perl,
And by opposing end them? To die(): To sleep()
No more; and by die() to say we exit(),
The heart-ache of the thousand malloc()s
That c code is heir to, ’tis a consummation (of ram)
Devoutly to be wish’d to die() when we forget to free(),
To sleep(): perchance to dream(): ay, there’s the rub;
For in that sleep() of die() what random() instructions may come
When we have shuffled off other's poor performance,
Must give us pause: there’s the respect That makes durability of so long C;
Burma Shave
For who would bear the whips and scorns of n00bs,
The oppressor’s wrong, the proud man’s memory managed tools,

Embedded Systems

[Anonymous Coward]

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'.

Re:Embedded Systems

[jythie]

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.

Re:Embedded Systems

[Tom]

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.

Re:Embedded Systems

[chuckinator]

I agree with PP and GP, but there's more to it than just that. Software is like an organ of your computer; your computer typically won't do much worthwhile if there's not a whole bunch of the things working together to make complete systems. Almost every one of the higher level languages are implemented in C at some point in the software stack. Some might argue that certain JVM languages like Scala and Groovy and Clojure are written in pure java, but guess what? The JVM is written in C. Almost every piece of software out in the wild is either written in C or depends on critical components written in C all the way down to the operating system. If you're running embedded, you might not have an OS, but you probably should be using C on microcontrollers and embedded systems unless there's a real good reason not to.

Very relevent for small target embedded stuff.

[Ihlosi]

C is the high-level language there. If you want actual control over your target, you'll need to use assembly.

Re:Very relevent for small target embedded stuff.

[aralin]

The thing is, if you use structures with bit fields, C will not optimize the manipulations with them correctly. So you end up doing a lot of hand-holding in driver development in C. You have to be very much aware of the code being produced. It is not uncommon that you check specific inner loop sections to see exactly how they are being compiled and then based on the result and number of instructions might need to rewrite the C part or even just insert the assembly code directly.

Re:Very relevent for small target embedded stuff.

[mean pun]

.. or at least people who think they are clever. Occasionally they are right.

Re:Very relevent for small target embedded stuff.

[TheRaven64]

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.

Re:C is very relevant in 2014,

[gsslay]

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.

Re:C is very relevant in 2014,

[Viol8]

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.

Libraries

[heikkile]

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.

Re:C is very relevant in 2014,

[TheRaven64]

There are good reasons and bad reasons why C is still popular.

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.

Re:C++ is C

[luis_a_espinal]

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.)

Re:First post

[NoNonAlphaCharsHere]

We're talking about C. You want the zeroeth post.

Re:C is very relevant in 2014,

[juanfgs]

. As a long time C hack (still am) I concur.

Behold. A C program that has gained sentience.

Re:C is primordial

[rioki]

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.

Re:First post

[Letophoro]

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.

Re:C is very relevant in 2014,

[gweihir]

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.

Re:Very much so!

[jlar]

But C++ is a thousand times more than "C with objects".

I believe the above quote speaks for itself...

Re:Very much so!

[iMadeGhostzilla]

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.