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: , ,

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

  5. Marcos says:

    In your original article, how did you come up with “around 98% of the new CPUs produced each year are embedded”?
    Is this information still valid? (For instance, it is used in the Wikipedia page for “Embedded Systems”).

  6. Euripedes says:

    Just a quick answer for you:
    C is for sure a error prone language and puts a lot of burden on the engineers shoulders. But you don’t need to have everything on your hands, tools and process will help to have better code. Is it solved? No it’s not. But it’s possible to write good code in C.

    About Rust I’ve been looking into it for some time now and it’s a promissing language but I feel that it’s not ready for embedded systems yet. The tooling needs to improve to make it easy to run projects using it.

  7. David MARTIAL says:

    Well, I’m a bit late on the topic but stil, it is really important to add my pince of salt to the debate.

    First, I’m a french freelancer and as a 30 y/o developer, began with basic programming then Pascal, assembly, later C and now I’m stuck with embedded C++ for which I’m a strong promoter.
    I can state that assembly is really simple provided that you now Boolean Algera as well as decimal and C language is not hard !

    It’s really a rather good way to do everything that does not compromise high level perspective of an application but does not prevent you to embed assembly code. That what every “C” developers are doing those days. Other languages can’t allow that efficiently.
    Further, mapping generated assembly to the source code is relatively easy.. Does the newcomers check for generated code ?
    From my experience in the field It’s not uncommon that compilers can do really nasty things in your back; your article about switch case statements is a good illustration, those of you that used gcc 2.95 can attest this statement.

    Anyway the current trend in programming is not toward “blind” languages for lazy developers than one can find on platforms having
    32Gb of ram … I’m completely disappointed when I see windows running on current generation processors ! That why I’m running Gentoo …

    Considering the difficulties involved when trying to qualify a given embedded function, no one wants a journey man in that particular field especially when your life is under control of that system, imagine if your Boeing shuts down with 300 lives inside after 248 days of continuous operation, lol ?

    Since I’ve spend my entire career correcting software due to journey man workers not having a clue about what is going on under the hood. Every managers nowadays seems to underestimate the fact, that why Chinese embedded devs contingent is growing rapidly, also because almost everything is done there..

    The current trend toward embedded is C++ with strong meta programming and compile time work offload, that the only thing that can replace ADA and give strong assertion about the safety and run time efficiency and security.

    STILL you can do bugs in C++.

    The free lunch is really over for embedded developers, Arduino is a good starting point but don’t imagine an ECU or a autonomous car be as simple as programming a single threaded garden management software.

    Yeah threading !!! Now ESP32 is dual core and I did not even mention the difficulties involved to that particular way of doing things.

    When I look at open source software : OpenTX, Deviation, GrBl, those I’m currently working on, and many other can have illustrated the fact, not seing any single memory barrier for massively asynchronous computing let me tell you that’s not the lunch but the game that is OVER.

Leave a Reply