Software engineering is on the lookout for better ways to develop software. The solutions will come from a variety of sources. Process change, integration of new tools, and development of skills are most definitely part of the answer. However, the success of any such efforts will be directly conditioned by the technological foundations on top of which all this is built — and the programming language is a strong part of this.
MISRA C is a set of software development guidelines for the C programming language developed by MISRA (Motor Industry Software Reliability Association). Its aims are to facilitate code safety, security, portability, and reliability in the context of embedded systems. MISRA-C is a great initiative to improve the quality of C development, but how easy is it to follow? How easy is it to verify? How much does it really bring to the table? And what's left to improve once all this effort has been taken into account? Wouldn't it have been better to start with a language that already addresses initial safety objectives?
As is often the case in this kind of situation, the answer varies. But intellectual and industrial pragmatism calls for investigation.
A little over 40 years ago, the US Department of Defense (DoD) conducted its own investigation and issued the specification for a new programing language. The result, Ada, was named after Charles Babbage's assistant, Ada Lovelace (1815–1852), who is credited with being the first computer programmer. In order to save massive amounts of money in software development, Ada was supposed to replace all others used at that time in the military's embedded systems. The DoD was so enthusiastic that it put a mandate in place, pressuring developers to use Ada for all military applications. Alas. ten years later, recognizing the fact that the language had not caught on the way they had hoped, fighting against a growing C++ wave followed by a Java wave, the so-called Ada mandate was dropped, and with it much of the Ada-industry that had been built around it.
Much, but not all. A few years before the revocation of the mandate, a new version of the language had been designed, and an open-source project had been funded to make sure a reference implementation was available. Over the following years, during the late 1990s and, more notably, the 2000s, while most Ada vendors were progressively steering their customers away from Ada, that open-source reference implementation was finding its way in the hands of a small commercial entity. Led by a team of researchers, this entity thrived on the market left by others, providing support for modern architectures, completing the tool suite, and enhancing the language. Millions of lines of code in military applications can't be re-written in a day, or in ten years, for that matter. Thus, little by little, rehost after rehost, and modernization after modernization, most of the remaining Ada market ended up using this tool, which is known as GNAT.
The time has come for Ada (Source: pixabay.com)
The story could stop here. However, the fact of the matter is that Ada didn't fall out of fashion because of lack of technical merit, it did so due to lack of appropriate tools (and maybe because people don't like to be ordered to do anything, let alone by the DoD). Three decades later, the technology has matured into a modern programming language environment tailored for embedded software development, with a clear edge towards reliability requirements. It's available for a wide range of platforms, from large systems hosted on x86 processors to small bare-metal targets such as the ARM Cortex-M0. The last revision of the language, Ada 2012, introduces unique specification and verification features, such as contracts-based programming that allows specifying constraints and behavior requirements in the source code itself. Furthermore, it also supports static analysis capabilities far beyond those commonly available for other languages.
None of this would be of any use if the software ecosystem was the same as that of the 1980s. Today, however, software is becoming ubiquitous, and it's becoming ubiquitous in systems on which our safety depends. There are more lines of code in a high-end car than in a commercial airplane, and this is not even talking about autonomous (self-driving) vehicles. Hospitals are filled with massive amounts of automation in places like the ICU and the OR, where a millimeter, a milliliter, or a millisecond can mean the difference between life and death. And what can we say about the army of connected devices growing in front of our eyes, ready to leap for our throats at the smallest buffer overflow?
Ada is here, off-the-shelf, released from its past DoD constraints, tested and improved over more than three decades of service in the most demanding environments. Most languages talking about safety today actually mean memory safety. Ada considers safety and reliability at the architecture and requirements level, enabling automatic verification from multiple angles. All of this on a single integrated formalism — the programming language itself.
Had Ada been used in any market less conservative than aerospace and defense, it probably wouldn't have survived its lack of time-to-marketness. Other languages of high technical merit didn't get that lucky. Fortunately, this time is now behind us. Listening to people that come to me, it is clear that a new generation of developers is open to consider Ada for a much more diverse set of applications. The time has come for Ada in the industry. The needs are here. The technology is here. There's never been a better time to revisit Ada!
Quentin Ochem has a software engineering background, specialized in software development for critical applications. He has over 10 years of experience in Ada development. His responsibilities at AdaCore include leading technical account management, driving business development, and following projects related to avionics, railroad, space, and the defense industries.