Is C Passing?

5/31/2002 10:21 AM EDT

One of the first comments I received in response to my previous editorial ("Code of Conduct," May 2002) was the following:

"You're obviously not a very good programmer and are using an archaic language. Nearly everything you said was biased toward mediocrity. Those of us Ada professionals wish that you would speak for yourself."

Though quite rudely put, the author does suggest an interesting possibility. Could the choice of programming language alone significantly improve the quality and safety of our finished products?

Of the eight suggested professional "ethics," three might be removed from the list if we all used a better language. Such a language would at least need to support exceptions, have strict syntax rules, and be strongly typed.

The C programming language fails on the first two counts. C++ adds support for exceptions but is crippled by not requiring programmers to use them. Among the "well-known" languages, only Ada and Java meet all three requirements. Both also offer language-level support for multithreading, which enhances program portability. Yet few embedded programmers use either language.

A recent subscriber study suggests that almost three-quarters of you use C regularly. C++ is used by about half, with a slow but steady erosion of C's relative numbers in recent years. Assembly language remains almost as popular as C++, though the trend with that language is clearly toward decreasing use. Despite its strengths, the use of Ada-currently below 5%-is also on the decline. And though its use is higher and on the increase, Java has a long way to go before it achieves acceptance within the embedded community.

Ignoring for a moment the many practical issues involved in changing languages, why not consider a switch? Of course, not all of us develop systems with safety issues. But perhaps those who do ought to take the prospect of language selection seriously at the outset of new projects. How many bugs need to be preventable to make such a transition cost effective?

Many recognize C's weaknesses and some, like the UK's Motor Industry Software Reliability Association (www.misra.org.uk), have even laid down complex ground rules for its use in safety-critical systems. So why stick with it at all? Why should we allow past practice to dictate future language choices? Will it take a future catastrophe to get us to make the change we should today?

Don't get me wrong. I love C. It is my first language and the one I use most competently. In an ideal world, though, the language decision should not be made based on our personal biases and experience. This is a decision that should be based solely on professional standards. But how can we compare languages analytically and measure the results of a transition from one language to another? It would be nice if there were easy answers.

Unfortunately, even if every one of us did switch to some "safer" language, miscommunication and logical errors would continue to be part and parcel of our discipline. To produce quality maintainable code, it would still be necessary to comment our work well, use version control, perform code inspections, and test early and often. Though compilers might be able to protect us from shooting ourselves in the foot, they'll never stop us from being entirely too human.

Return to June 2002 Table of Contents