Dennis Ritchie and C for embedded

I was, of course, saddened to hear the recent news of the death of Steve Jobs. Since then, the Internet has been buzzing with stories, anecdotes and speculation about him. As a result, the news of the death of another key figure in the computing world barely got a mention: Dennis Ritchie died on 12 October 2011. Although not so much of a household name as Jobs, there are many [including myself] who feel that his contribution to the technology that we all use every day was, at least, comparable.

Ritchie is most well known as the creator of the C programming language, which is the most widely used language for embedded software 30+ years later. He was also a key developer of UNIX, which led directly to Linux, which is, again, widely deployed by embedded software developers. In musing upon his achievements, I started thinking some more about the use of C for embedded …

There has been a lot of discussion about the use of C for embedded programming lately. I talked about the topic here, for example. Most commentators seem to agree that C is far from ideal, but is a reasonably sensible compromise. So, what is wrong with it and how could that be addressed.

C has two key attributes that make it a “traditional” high level programming language: the means to code in a structured fashion and typing of data, which enables the programmer to delegate all matters of data representation and manipulation [more or less] to the compiler. Both of these attributes are good, but maybe not good enough.

From a structured code point of view, C is rather limited. Everything is very open and there is not much hierarchy. A language with object oriented characteristics, like C++, might be better for larger projects. More importantly, data typing in C is weak. It does what it is supposed to do, but the rules are not strongly enforced and there are numerous opportunities for programmer error. Again C++ provides some opportunities for improvement. Maybe a language that was engineered from the ground up to have strong structure and rigid typing, like Ada, might be a better option.

The alternative is to go the other way. As I started out doing embedded coding in assembly language, that is where I base my perspective. I take the view that an embedded developer needs the control and power of assembly, but can benefit from any productivity enhancers that are available. Maybe the best thing to do is to take away data typing entirely. Once the programmer knows that it is their responsibility, I think [perhaps naively] they are likely to be more careful.

So, what language would make sense? If you look at the origins of the C language [and Ritchie’s paper The Development of the C Language is a good place to start], you will see that it evolved from a language called B, which, in turn, was inspired by another called BCPL. The BCPL language was designed to provide assembly programmers with the productivity benefits of a structured programming syntax and was very successful in the late 1960s and 1970s. Interestingly, it is still being used and developed today, so maybe it really is an option.

If you are not familiar with his work, I encourage you to Google Dennis Ritchie. I am sure that you will be impressed and agree that his death is a sad loss to the world of embedded software.