原创 Remembering Robert Dewar

Robert Dewar passed away last month, June 30 at age 70.

Most readers of this site probably don’t know the name. Dr. Dewar was president and one of the founders of AdaCore, a leading supplier of support and services for Ada developers. He had a long career and contributed to many projects. He and Edmond Schonberg wrote GNAT, the FOSS Ada compiler which is part of the GNU compiler collection.

Unfortunately, I only knew Dr. Dewar peripherally but had marveled at his intellect. (AdaCore is swimming in really smart people.) According to his Wikipedia page his interests were quite varied, and he even starred in the titled role in The Mikado (one of my favorite theater events).

According to a recent AdaCore newsletter most of the company’s business is in the embedded space. Yet, as I mentioned, probably few readers of this, the biggest embedded systems site, know of Dr. Dewar or have much knowledge of Ada.

Most of us use C or C++, a language that now has ancient roots. Ada is also old, dating to the early 80s, and has been through a number of revisions. In my opinion, we, the embedded community, haven’t given the language a fair chance. Only a few percent of us report using it in real products.

C is great; it’s a very compact way of expressing complex ideas. (One Ada user complained to me that C is for people who don’t like to type!) If you grew up in the early embedded days where everything was done in assembly, that transition to C was like a breath of fresh air. Now we could do in one line what might take pages using mnemonics.

C was properly designed for machines with limited memory and CPU cycles, since a 4 MHz clock was unheard of when it first appeared. But we’re still paying for those design choices. Divide by zero all day long. Exceed array bounds with gusto. If malloc() fails, well, who cares? Who even checks its return value?

Ada was designed to help us write correct code. It’s demanding, accepting only valid, strict syntax. With C one can practically compile the telephone directory. Most programmers hate Ada after their first experience with it. Those who soldier on through a few projects usually love it.

C developers have some really good reasons to eschew Ada. After all, we may be working on projects that already have massive amounts of C code. In many cases it’s a poor business decision to change languages in the face of enormous piles of legacy code. And it’s really hard to find people versed in Ada.

There are bad reasons as well for discounting Ada. People complain that it’s slow or generates bloated code. Yet that simply isn’t true anymore. Estimates peg the Ada tax at under 10% compared with C. I often respond with a question: what’s the difference in code size or execution speed between, say, IAR’s C compiler and GCC? Or between Arm’s and Green Hills? It’s probably a dumb question in that scores will vary depending on which feature you’re using; trig may be better on one product while memory management better on another. The differenc

e is likely in the noise, which is pretty much what we can say about C vs Ada.

Others bemoan the increased development time of Ada projects. There’s some truth to that, primarily because so many are safety-critical with an extensive certification process. Remove that and things change. Ada programs experience about a tenth the number of bugs of C systems (see Table 1 in Software Static Code Analysis Lessons Learned, Andy German, QinetiQ Ltd., Nov 2003, Crosstalk). Since the average embedded team spends half the schedule in debugging, that argument is spurious.

Some dismiss the language because, as they say, it can’t be used on microcontrollers. Except it can: It’s available for a number of MCUs including the Cortex-M family and even for 8 bit AVRs.

The argument that Ada developers are a scarce resource is both true and important. It would be foolish to learn a new language while using it on a real product. In the 90’s and first part of this century I ran into a number of projects that failed when teams adopted C++ with no OO experience. One needs a chance to make mistakes, build practice throw-away projects. And Ada is complex. The John Barnes Ada 2005 book is over 800 pages. My recommendation is, as always, learn new things and push your mental boundaries.

Robert Dewar spent a big part of his career working on and advocating for Ada. You’ll find it used where getting code right is critical. If you fly, thank his legacy for those routine trips that are never marred by an avionics glitch.