embedded software boot camp

Real Men [Still] Program in C

Wednesday, March 29th, 2017 by Michael Barr

It’s hard for me to believe, but it’s been nearly 8 years since I wrote the popular “Real Men Program in C” blog post (turned article). That post was prompted by a conversation with a couple of younger programmers who told me: “C is too hard for programmers of our generation to bother mastering.”

I ended then:

If you accept [] that C shall remain important for the foreseeable future and that embedded software is of ever-increasing importance, then you’ll begin to see trouble brewing. Although they are smart and talented computer scientists, [younger engineers] don’t know how to competently program in C. And they don’t care to learn.

But someone must write the world’s ever-increasing quantity of embedded software. New languages could help, but will never be retrofitted onto all the decades-old CPU architectures we’ll continue to use for decades to come. As turnover is inevitable, our field needs to attract a younger generation of C programmers.

What is the solution? What will happen if these trends continue to diverge?

Now that a substantial period of years has elapsed, I’d like to revisit two key phrases from that quote: Is C still important? and Is there a younger generation of C programmers? There’s no obvious sign of any popular “new language” nor of any diminution of embedded systems.

Is C Still Important?

The original post used survey data from 1997-2009 to establish that C was (through that entire era) the dominant programming language for embedded systems. The “primary” programming languages used in the final year were C (62%), C++ (24%), and Assembly (5%).

As the figure below shows (data from Barr Group‘s 2017 Embedded Systems Safety & Security Survey), C has now consolidated its dominance as the lingua franca of embedded programmers: now at 71%. Use of C++ remains at about the same level (22%) while use of assembly as the primary language has basically disappeared.

Primary Programming Language

Conclusion: Obviously, C is still important in embedded systems.

Is There a Younger Generation of C Programmers?

The next figure shows the years of paid, professional experience of embedded system designers (data from the same source). Unfortunately, I don’t have data from that older time period about the average ages of embedded programmers. But what looks potentially telling about this is that the average years of experience of American designers (two decades) is much higher than the averages in Europe (14 years) and Asia (11). I dug into the data on the U.S. engineers a bit and found that the experience curve was essentially flat, with no bigger younger group like in the worldwide data.

Years of Experience

Conclusion: The jury is still out. It’s possible there is already a missing younger generation in the U.S., but there also seems to be some youth coming up into our field in Asia at least.

It should be really interesting to see how this all plays out in the next 8 years. I’m putting a tickler in my to-do list to blog about this topic again then!

Footnote: Same as last time, I’m not excluding women. There are plenty of great embedded systems designers who are women–and they mostly program in C too, I presume.

Tags: , ,

4 Responses to “Real Men [Still] Program in C”

  1. Michael Barr says:

    Just discovered I did have some 2011 data on average years of experience from an earlier survey. I blogged about that here: https://embeddedgurus.com/barr-code/2011/02/embedded-software-community-survey-findings/.

    At first glance, that data seems to say us that the worldwide average embedded systems designer has not aged in the last half decade. Too bad that’s not been true for me on a personal level!

  2. Cliff Brake says:

    As the Linux kernel is written in C, C will remain relevant in embedded systems for a long time. The arguments for why the Linux kernel still uses C are interesting, and may also be relevant for non-Linux systems. The Linux kernel contains many advanced computer science concepts and data structures, and is a good example that cool stuff can be done in C (example is http://bec-systems.com/site/115/the-linux-kernel-container_of-macro). I typically use C++ for Linux applications, but every time I return to do Linux kernel work in C, I find it refreshing.

  3. Majo says:


    I’m a 22 years old computer science student in Germany at the end of his bachelor study and what I can say about C, that I know the importance in C and know, that it will unfortunately probably continue existing for many many additional years.

    My favorite topic within computer science is information security, and my opinion on C is, that I hate it. I know that you can control almost every resource of a system, which brings enormous performance advantages, which is one of the reason, why C is widely used in (embedded) systems programming. But C puts a lot of (unnecessary) responsibility burden on programmers.

    For me C is the language, which brought us Heartbleed and thousands of other software vulnerabilities which are hunting us everyday and we can’t do much in the short and in the mid-term, because still a lot of security critical software is written in C and people are continuing writing security critical software in C, although it’s not always necessary.

    I think C makes it unnecessarily hard to write good, reliable and secure code, because you highly have to concentrate on controlling your resources and your assumptions you make while programming. I don’t consider it as a skill that you know every piece of weird behavior of C (e. g. signedness errors) just because you learned it bitterly by yourself after several months of experience.

    The only reason what makes sense to me, why a an error-prone, weakly typed language like C is still so wide-spread is, that it _was once_ the best language few decades ago and therefore was leading to mature toolchain, which we can use today. Not because it’s well designed or can’t be fundamentally improved.

    If I see fellow students, which are feeling proud of telling me that C is their favorite language, I either shake my head or mentally laughing at them, knowing that they do and will writing broken code, like which is happening from day to day to kinda every programmer, who is writing C code. Not because I think s/he is dumb, but because I think C makes it easy to write bad code and I consider C as an outdated, broken language, which shouldn’t have a future regarding to our requirements on safe and secure software/hardware today. I think these are the same students, who would agree, that “real men still program in C”. I still don’t understand, what’s so manly about it to write broken, unreadable (using a lot of macros with a lot of bit shifting is certainly very manly!) and insecure code.

    And the sad thing is, in a lot of cases we probably don’t have to stick with C and it’s lack of constructive quality assurance properties.

    > There’s no obvious sign of any popular “new language” nor of any diminution of embedded systems.

    The most obvious sign of a popular new language which could in my opinion probably compete with C is Rust [0].
    I’ve never written much code in Rust, but what I’ve heard and read about it, is, that it’s giving me hope on a future, where people can develop systems low-level profiting of state-of-the art thoughts on safe and secure programming without being constraint by and old and broken language.

    Rust is designed as an systems programming language with safety and performance in mind. If you made it to successfully compile Rust code, you are guaranteed that your binary achieve certain (safety) properties. Why should someone voluntarily plague oneself with C, compiler flags and static analyzers, when he gets the same or better with Rust by design?

    I hope I could clearly express my thoughts on C and why I don’t like it.

    Best regards,

    [0] https://www.rust-lang.org/en-US/

  4. Paul Penrose says:

    Have you looked at the Rust programming language? It seems to me to be a potential replacement for C in the embedded specialties. From what I can tell, it would encourage better practices than are currently used. The Toyota unintended acceleration case and recent IoT failures clearly illustrate that there is much room for improvement. Obviously new languages and RTOSes are not the answer to all the problems, but if we can address the simplest and most common mistakes this way, we will have more time and energy to chase the more complex issues.

Leave a Reply