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
Aug 3, 2021
I just discovered that Norland Nannies -- who can command a salary of $170,000 on a bad day -- are trained in self-defense and defensive driving....
Aug 3, 2021
Picking up from where we left off in the previous post , let's look at some more new and interesting changes made in Hotfix 019. As you might already know, Allegro ® System Capture is available... [[ Click on the title to access the full blog on the Cadence Community si...
Jul 30, 2021
You can't attack what you can't see, and cloaking technology for devices on Ethernet LANs is merely one of many protection layers implemented in Q-Net Security's Q-Box to protect networked devices and transaction between these devices from cyberattacks. Other security technol...
Jul 29, 2021
Learn why SoC emulation is the next frontier for power system optimization, helping chip designers shift power verification left in the SoC design flow. The post Why Wait Days for Results? The Next Frontier for Power Verification appeared first on From Silicon To Software....

featured video

Vibrant Super Resolution (SR-GAN) with DesignWare ARC EV Processor IP

Sponsored by Synopsys

Super resolution constructs high-res images from low-res. Neural networks like SR-GAN can generate missing data to achieve impressive results. This demo shows SR-GAN running on ARC EV processor IP from Synopsys to generate beautiful images.

Click here for more information about DesignWare ARC EV Processors for Embedded Vision

featured paper

PrimeLib Next-Gen Library Characterization - Providing Accelerated Access to Advanced Process Nodes

Sponsored by Synopsys

What’s driving the need for a best-in-class solution for library characterization? In the latest Synopsys Designer’s Digest, learn about various SoC design challenges, requirements, and innovative technologies that deliver faster time-to-market with golden signoff quality. Learn how Synopsys’ PrimeLib™ solution addresses the increase in complexity and accuracy needs for advanced nodes and provides designers and foundries accelerated turn-around time and compute resource optimization.

Click to read the latest issue of Designer's Digest

featured chalk talk

Security Regulations Drive Requirements

Sponsored by Mouser Electronics and Silicon Labs

IoT Security certification schemes can be complex, but security identities and security certification inheritance can make this aspect of your IoT design quite a bit easier. In this episode of Chalk Talk, Amelia Dalton chats with Mike Dow from Silicon Labs about the current state of global security regulations, the difference between physical and logical attacks, and how Silicon Labs SoCs and modules can help you solve the security demands of your next design.

Click here for more information about Silicon Labs EFR32xG21B SoC & xGM210P Modules with Secure Vault