Learning from an Ada Neophyte

Delivering an application that does what it was designed to do is the goal of most developers. One way to accomplish that is to use tools that enhance the development process. Using MISRA coding standards is one approach to improving C/C++ development. Another method is to use SPARK, a subset of Ada designed for safe and secure applications.

Of course, taking on a new programming tool is not something to do lightly. I recently served as one of the judges for Adacore’s “Make with Ada” competition. Stephane Carrez of Issy Les Moulineaux, France took first place with a network-traffic monitoring tool called EtherScope. In second place was German Rivera of Austin, who developed an Autonomous Car Framework for the NXP cup race car. But what I want to highlight is the feedback from the third-place winner, Shawn Nock from London, Ontario, who developed a Bluetooth Beacons “iBeacon” using Ada.

The reason is that Shawn is a C programmer who had not used Ada before competing. “Developing the beacon in Ada (a language I don’t know well) took roughly the same time as the similar functionality in C,” he wrote in his blog, “and I have more confidence in the Ada code.” This came down to a few simple factors:

“I find Ada’s syntax to be intuitive. I’ve done a fair amount of work in Python, so I found the block notation and indentation to be comfortable immediately. Unlike Python, Ada retains semicolons as statement delimiters [making] me all warm and fuzzy.

“I found it natural to draft my interfaces in spec files. In C, I’ve acquired the bad habit of writing code and interface at the same time in .c files and back-filling header files when my compiler complains. I could have always done this better in C, but the context switch to Ada allowed me to see the advantage clearly.

“More opinionated compiler—I’ve run external linters and static analysis tools in my VCS commit hooks for ages, but there are 90 ways to write C and a thousand tools... having the compiler express strong opinions and enforce them at compile time saved me time. From syntax checking to style checking; I didn’t find myself needing to spend time search [sic] out good tooling to start writing decent code. I imagine that when working on a team, it’s easier to agree on (and enforce) a list of compiler flags than a whole ecosystem of tools.

“GNAT—It’s a part of the GCC. This is perhaps a downside for some embedded engineers... but I enjoy working with GCC. It’s consistent, available on nearly every platform, well maintained, and free. With GNAT, I only needed to add a single tool to my development ecosystem to get started on Ada.

“I didn't spend anytime [sic] in the debugger. Once I convinced GNAT of my intentions on with some pretty intense compiler flags (-gnatg -gnatp -gnatn2 -gnatwa -gnatQ -gnatw.X); my software tended to Just Work.”

Most of the projects targeted microcontrollers like STMicroelectronics’ 32-bit STM32 family, which includes Cortex-M4 and Cortex-M7 solutions.

This type of feedback is not limited to individuals in a competition. I recently hosted Adacore’s webinar, “Building High-Assurance Software without Breaking the Bank,” where Protean Codes’ Rod Chapman talked about a number of projects that utilized SPARK. The bottom line was that the safety-critical projects presented were completed on time with fewer errors, thereby reducing the amount of testing required. This reduced project costs.

Static- and dynamic-analysis tools are being used for C, C++, and Java applications to improve code quality. Unfortunately, they fall short compared to SPARK. C and C++ will remain the primary tools for embedded applications for a number of reasons, but if you’re searching for that edge, SPARK may be worth a look.