On languages - Embedded.com

On languages

Some years ago compiler vendor Keil Software (now part of ARM) ran an ad in Embedded Systems Programming magazine (later known as Embedded Systems Design, and now embedded.com) for their new compiler: COBOL for the 8051:

It was a joke, and ran in the April (April Fools) issue. What a funny and absurd product idea! COBOL for embedded? And COBOL for an 8051! I called the company’s president and congratulated him for his sense of humor.

He told me they received orders for the product!

That reflects a certain mindset we still see in selecting languages for embedded work. Aspirations seem to trump reality.

You can’t read Slashdot or similar web sites without seeing a discussion about the language de jour. Is D the new hot way to write code? Swift? I get emails all the time from people wanting information about crafting their firmware in C#. It’s not unusual to hear someone say that the whole world is moving towards Java, and to not do so means getting left behind.

What whole world? In fact, in the embedded space, to a first approximation only two languages are used: C and C++. Embedded.com’s data shows the primary language used by readers (the vertical axis is percent):

It’s clear that, surprisingly, even C++ isn’t gaining market share on C.

In language selection one must consider the availability of developers. If you can’t hire engineers who are versed in a particular lingo, then count on long and expensive training or failure.

I was called in to help with a foundering project in Sweden, which was being written in C++. I thought the language was a natural match to the application. But why was that choice made? The VP told me that he had read, in Business Week, that C++ was going to make everything instantly reuseable so had dictated its use.

There were 40 developers involved, and only one, a new graduate, had any object-oriented experience. The other 39 were trying to learn it on the job. That’s a recipe for disaster. They needed a practice, throw-away project to get experience. One where mistakes were fine since it wouldn’t ship.

C has hung on in this space for 30 years and shows no sign of going away. There are better choices now; I wish we could transition to Ada or, even better, SPARK. But that won’t happen unless there are trained engineers available.

What’s your take? Are C and C++ here to stay?


Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges, and works as an expert witness on embedded issues. Contact him at . His website is .

14 thoughts on “On languages

  1. “It is well documented that the majority of software failures are not a result of programming failures per se but are instead requirements/integration defects.nnThose will not go away whether the software is written in C, assembler, COBOL, Ada or a new

    Log in to Reply
  2. “C is here to stay. Apart from being a conservative bunch, Embedded Engineers have tool chains/compilers to contend with. If Texas Instruments, NXP, ST or whoever don't release for example a Java compiler etc. for their device Java is not going to be us

    Log in to Reply
  3. “As the surveys show, C and C++ are the languages that dominate the embedded firmware landscape. This is, in part, due to the lack of tools that support other programming languages for embedded targets. nnHowever, in recent years, the availability of pro

    Log in to Reply
  4. “Also note that you can mix and match, using an appropriate tool for the task but don't go crazy. For example, Lua/LuaJIT and Python/MicroPython interact very well with C code. So you can do things like use MicroPython for high level control, with C co

    Log in to Reply
  5. “If I understood Jack correctly, the problem in Sweden was management, not engineering, deciding on a programming language based in misinformation and ignorance rather than technical merits. Additionally, no language was going to succeed as long as it was

    Log in to Reply
  6. “Yes, no doubt the C languages are here to stay and most of my career is with those, but when I have a choice I always choose Forth which I've brought up on numerous platforms, even 6805 with ADA selective wait implemented in it !. I found 4-10 times bet

    Log in to Reply
  7. “I too use Forth and have for over 30 years now. Half my projects use Forth and the other half use C and C#. The productivity that Forth offers is limited by the relatively unsophisticated development tools, which is not a problem until your product gets c

    Log in to Reply
  8. “RichardnnYour experience with Forth mirrors mine. I really like the highly interactive nature of Forth, but having the compiler verify function prototypes etc is a huge boon that cannot be ignored.n”

    Log in to Reply
  9. “Most certainly in embedded work C isn't going away anytime soon (C++, which has always been over-hyped, I'm less sure about). By necessity most of the coding I do is in C, but I'm not at all averse to using Pascal, and family, where tools are available (A

    Log in to Reply
  10. “I've been writing embedded code in C for a while now, and have been also been developing Windows / Mono code in .NET. for much longer. I think that there is benefit in evolving to someplace in the middle for embedded code. C is extremely well supported a

    Log in to Reply
  11. “Glad to see others are using C#. It can be used to model HW logic and data flow with the driver and application code.nnI have also p;arsed C source to generate micro code for an FPGA FSM.nnYHE C# debugger and compiler are excellent. “

    Log in to Reply
  12. “While I agree that C is likely here to stay, I think (hope) that MISRA C, or a derivative, will eventually become a best practice for embedded C programming. C gives you more than enough rope to hang yourself. A safer subset of the language, combined with

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.