feature article
Subscribe Now

Rooting Out Software Heresy

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.

Leave a Reply

featured blogs
Jun 7, 2023
We explain how semiconductor designers create reliable, safe, and secure aerospace designs by leveraging IP and standards from automotive chip designs. The post Why Aerospace Semiconductor Designers Are Taking a Page from Their Automotive Friends appeared first on New Horizo...
Jun 6, 2023
At this year's DesignCon, Meta held a session on '˜PowerTree-Based PDN Analysis, Correlation, and Signoff for MR/AR Systems.' Presented by Kundan Chand and Grace Yu from Meta, they talked about power integrity (PI) analysis using Sigrity Aurora and Power Integrity tools such...
Jun 2, 2023
I just heard something that really gave me pause for thought -- the fact that everyone experiences two forms of death (given a choice, I'd rather not experience even one)....

featured video

Efficient Top-Level Interconnect Planning and Implementation with Synopsys IC Compiler II

Sponsored by Synopsys

This video shows how IC Compiler II and Fusion Compiler enable intelligent planning and implementation of complex interconnects through innovative Topological Interconnect Planning technology - accelerating schedules and achieving highest QoR.

Learn More

featured paper

EC Solver Tech Brief

Sponsored by Cadence Design Systems

The Cadence® Celsius™ EC Solver supports electronics system designers in managing the most challenging thermal/electronic cooling problems quickly and accurately. By utilizing a powerful computational engine and meshing technology, designers can model and analyze the fluid flow and heat transfer of even the most complex electronic system and ensure the electronic cooling system is reliable.

Click to read more

featured chalk talk

Beyond the SOT23: The Future of Smaller Packages
Sponsored by Mouser Electronics and Nexperia
There is a megatrend throughout electronic engineering that is pushing us toward smaller and smaller components and printed circuit boards. In this episode of Chalk Talk, Tom Wolf from Nexperia and Amelia Dalton explore the benefits of a smaller package size for the SOT23. They investigate how new package sizes for this SMD can lower your BOM, decrease your board space and more.
Oct 20, 2022
28,453 views