For those of you who don’t regularly visit the comments at http://www.journalforums.com/ (and you should), my piece two weeks ago on “Taming C?” generated a number of comments. These got me thinking. The outcome of these thoughts seemed sufficiently relevant to all regular readers of ETJ that it was worth writing a full-length article rather than just posting replies.
The article started, “There is a problem with the C programming language.” It went on to argue that using a subset of C, like MISRA C, and a static code analysis tool could produce better code – that is, code that would be less likely to crash or behave in unpredictable ways.
One of the comments, from david21001, really provided the jumping off point for this response. He said:
It’s not the language that’s the problem.
It’s the competency level of the user that is the issue.
There is absolutely NO need to change the C programming language, because companies don’t staff themselves with competent software engineers.
It is obvious this author has a hidden agenda — marketing and selling software tools, getting you to switch to an inferior product — the notion of using java for embedded development maybe.
I am not a gun or NRA nut, but to use their analogy very aptly in this context. It’s not the programming language, C (the “gun”) — it’s the user (== shooter)!
The programming language is not encouraging your staff to be mediocre and code poorly. Maybe you should consider hiring better personnel.
One of the pioneers of programming at the Cambridge Computing Laboratory said in the 1960s, “If this were the middle ages, programmers would be burning other programmers at the stake for heresy.” david21001 is clearly a believer in C, but I doubt that he would want to burn anyone at the stake.
And before we go any further in this discussion, I am disappointed that he thinks I have a hidden agenda: I had rather hoped that the agenda was specific and clear. So, to avoid all possible future suggestions that there is a hidden agenda, here it is.
It starts from the basis that a great deal of software development today, including software development for embedded systems, produces poor quality software that could be dramatically improved by the use of tools. Hardware engineers appear to be able spend thousands of dollars, or even tens of thousands of dollars, on boxes. Chip designers have software tool chains on their workstations that have cost tens or even hundreds of thousands of dollars to buy and many more dollars a year to maintain. For embedded system developers outside the safety-critical and aerospace/defence areas, however, there is evidence that management is reluctant to spend over a thousand dollars on tools after providing a PC and a compiler. At the same time, many of the tools available are perceived to be expensive (well, almost anything is expensive if your budget limit is $1K), difficult to use, or both. In fact, many of the tools are expensive and many of them do require the user to spend time in learning how they can be best deployed.
My agenda, when looking at the software development process, is to encourage embedded developers to use tools and to encourage tool providers to make better (and cheaper) tools available.
Is my agenda influenced by my ’marketing and selling software tools’? No, since I don’t market or sell software tools. Like many freelance journalists, I also provide advice to, and write for, commercial organisations from time to time. This inevitably includes working with companies that develop and sell software tools. But this doesn’t influence my writing in ETJ, except insofar as it provides a better understanding of the strengths and weaknesses of these tools: certainly, I do not regard any of them as perfect.
It was also suggested that part of my agenda might be ‘getting you to switch to an inferior product — the notion of using java for embedded development maybe.’ This suggests that Java is inferior to C for embedded projects. But is it necessarily wrong for all embedded projects? And is C necessarily right? Or ADA? Or C++? Or even assembler?
David May, who is both a distinguished academic at Bristol University and the CTO and founder of XMOS, says that programming languages are tools. Programmers should have a tool kit and use the appropriate tool for the job. Unfortunately, too many programmers know only one language in any depth. This makes it difficult for them to be objective about either their own favoured language or any other language: if all you have in your toolkit is a hammer, life is a search for nails.
It has been said that all men are convinced that they are great lovers, fantastic drivers and write good English. (That is if they speak English, they write good French if they speak French, etc). If they are programmers, they all write great code. I, naturally, write English fantastically well. However, I still run my copy through a spell and grammar checker, and then pass it through no fewer than two different (human) copy editors – the equivalent of static code analysis and code reviews – before it reaches your screen.
The English language is a fine and flexible thing, but it is still capable of producing ambiguities (was my comment about writing ‘fantastically well’ meant seriously or was it written tongue in cheek?) and sentences that are meaningless, although grammatically correct. Instruction manuals for consumer goods are notorious for being written in a language that leaves the reader totally bewildered when it comes to operating the product, even though it may well have been parsed by stringent grammar checkers.
The C programming language is also a fine and flexible thing, but is it really true that, ‘There is absolutely NO need to change the C programming language, because companies don’t staff themselves with competent software engineers.’ ?
Do companies not staff themselves with competent software engineers because they are too mean to pay a decent wage? Or is it that there are far too few competent software engineers in the market and companies have to recruit whomever they can to write the code that needs writing? If the latter, perhaps this might be a reason for using a restricted set of C. Companies in the aerospace and defence industries can afford to hire good people, and they do so. Yet they still insist on the use of restricted sets of languages and a wide range of tools in developing software.
For readers outside the USA, the National Rifle Association (NRA), the leading gun lobby in the United States, has a mantra, “Guns don’t kill people; people kill people.” Presumably the analogy with C is that it is not that C is the problem, it is the people using it who are the problem. This links in perhaps with the recent discussion about the FDA (the U.S. Government’s Food and Drug Administration) using static code analysis to identify software flaws in medical devices, including flaws that have killed people. Surely even the best programmer in the world, writing with a language that is close to perfect, would be happy to use a static code analyser and other tools to remove even the slightest chance of a programme causing someone’s death?
Maurice Wilkes is one of the pioneers of computing. He is reported to have said, “As soon as we started programming, we found to our surprise that it wasn’t as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.” The exact instant was over fifty years ago, and we have been following that path ever since.
And ever since then we have become used to the fact that most products that are based on software are to some degree unreliable, whether the end user knows it or not. This doesn’t mean that we should accept it: embedded software developers should be at the forefront of looking for ways of developing good software, not defending a language that, if used carelessly, can make matters worse.
