Names are strange, and programming language names can be even stranger. Given the thousands of languages that exist, it is inevitable that there are some strange ones out there. ENGLISH was a good name for what turned out to be a non-runner, and “The Last One” was a click-and-point code-generator, generating BASIC (one of the last of the acronym language names.) I have a weakness for the wacky – Python, for example was named after Monty Python’s Flying Circus – but also like the elegance of naming a language after a pioneer. occam was named after a fourteenth century philosopher, and while we still wait for a language called Grace or Hopper, the homage to Ada, Countess Lovelace, is still pleasing. By coincidence the 2009 Ada Conference UK was on Ada Lovelace Day (March 24th) – a day that celebrates women in technology and aims to encourage more women to enter technological roles. This seemed a good opportunity to look at some of the latest developments in Ada.
Developments? Isn’t Ada an old fashioned failure? Didn’t it more or less die when the US Department of Defense, which commissioned it in the first place, decided to abandon its mandatory use? Well, no. Ada is still in use for safety- and mission-critical systems, particularly for large systems. To be fair, there are reasons for people to be a little dubious about Ada. The first attempts by DoD and other defence organisations around the world to bulldoze through the use of Ada, while succeeding to the extent that it dramatically reduced the number of languages in use on defence projects, was premature. The development tools were not in place: in particular, the compilers were not ready. Since one of Ada’s strengths is the checking functions built into the compiler, this was a major drawback. There was also the issue of persuading programmers that it was worth their while to learn the language.
Since that early debacle, Ada has developed steadily. It has strong typing, modularity mechanisms (packages), run-time checking, parallel processing (tasks), exception handling, generics, and support for object-oriented programming, including dynamic dispatch. While Ada was developed specifically for safety-critical applications, there were still areas of ambiguity as well as problems with proving that a compiled Ada programme was safe and reliable, so two alternate approaches were developed, building on the formal definition of Ada: the Ravenscar Profile and the SPARK language.
Ravenscar is a small village in Yorkshire, England and was the setting for the 8th International Real-Time Ada Workshop (IRTAW) in April 1997. This workshop discussed the issues of implementing real-time programs, particularly concurrent real-time programs, reliably and efficiently, together with the related problem of verification. The workshop saw the route to achieving better programs as a profile, a formally defined sub-set of the Ada language that can be imposed by the compiler. Applying the Ravenscar Profile cuts out a lot of the Ada features, simplifying the run-time system’s semantics. A run-time implementation created using the profile is small and highly efficient. It is also possible to verify it for certification as part of the formal certification of a system to the highest integrity levels.
SPARK is developed and supported by Praxis, a company based in Bath, England, specialising in high integrity systems. While the website talks of SPARK Ada, and this phrase is used by other companies, Praxis normally speaks of SPARK not as a sub-set of Ada but rather as a “formally defined programming language based on Ada.” It is Ada “without the ambiguities.” To accompany SPARK, Praxis has also built the SPARK Examiner tool, which “checks the coherence of SPARK at every step.” With these tools, the designer defines “contracts” – definitions of what the programmes should do. The idea is that regular use of SPARK Examiner, from skeletal design through partial implementations to completion, ensures that the code that is passed to the compiler is free of bugs and meets the contracts. Praxis refers to the approach as doing software right, rather than testing for faults.
Although SPARK has been around for over 20 years and has an impressive record of delivering systems, Praxis is concerned that it has not achieved its commercial potential. At the Ada conference, Praxis announced a commercial tie-in with AdaCore. AdaCore, a Franco-American company, is best known for its support of the open source GNAT technology. GNAT is often thought of as, and used as shorthand for, the open-source compiler for Ada. But the technology not only includes the compiler, but extends to an IDE for Ada with a debugger, libraries and bindings, and other tools. AdaCore also supports a commercial version of GNAT, GNATPro. Now AdaCore is distributing SPARK Pro, a package of SPARK, SPARK Examiner and other SPARK tools plus the GNAT Programming Studio IDE.
Praxis has also created the SPARK Pro Blackbelt Edition, which will add to SPARK Pro the SPARK Proof Checker and RavenSPARK, a Ravenscar profile of SPARK for concurrent programmes. (This is getting just so incestuous – a family tree plotter would give up at this point.) AdaCore will also be taking over all support for SPARK, while Praxis will continue to develop the language and tools.
Given that Ada is going to be at home on large systems, it was not surprising to find product announcements for UML tools. Objektum Solutions is a small UK company that has developed a tool, LegacyBridge, for sucking legacy Ada into UML. Why would you want to do this? Defence, aerospace, transportation and all the other areas where Ada has been successfully deployed have very long product life cycles. Nuclear power plants last for many decades, aircraft fly for a long time, and so on. But during their lifetime they may need upgrades and modifications. If the design is captured in a modelling language, changes are easy to implement and their consequences are easier to predict. So being able to retrospectively build the model from working code has obvious benefits. Objektum has gone a step further: before UML, European avionics and space projects used the HOOD (Hierarchical Object Oriented Design) methodology, devised by the European Space Agency. LegacyBridge will also take the HOOD representations and translate them into UML as well.
New projects could benefit from an approach developed by Kennedy Carter, another UK company. This uses executable UML, a subset of UML that is semantically “cleaner” than full UML, and a SPARK generator, to move from UML into SPARK code. This work was carried out by Kennedy Carter and Britain’s Atomic Weapons Establishment (AWE).
AWE also demonstrated how to get SPARK Ada running on an 8-bit processor for embedded applications. Using a data logger application running on an Atmel AVR microcontroller, they were able to demonstrate that it was possible to develop SPARK Ada code, using the SPARK examiner and an AdaCore compiler, faster than creating the same application in C. The team used less-experienced staff for the development and were able to identify hardware issues more easily, as they had a very high level of confidence in the quality of the code.
Given the emotion that surrounds the choice of programming languages, there was surprisingly little evangelism during the conference, perhaps because the congregation and preachers were both in the same church. The Plenary opening was the closest it got, and Jim Sutton, of Lockheed Martin, wasn’t as much preaching the Ada gospel as showing that the true way to Ada was through Lean System Engineering. Perhaps it would be unfair to say that the impression given was that the result of the Lean techniques was a mathematical method of measuring common sense, but that is how it seemed.
The consequences of sin were spelt out in the opening slides: “only 36% of software projects started in 2006 … [were] successful,” “choosing the wrong language will ensure that the product will never ship,” and “most projects fail before programming begins.” Building from this was a series of steps that attempts to provide objective guidance in choosing the programming language that matches the project goals, using the subjective opinions of all the stakeholders, which could include the CEO, the customer, and consultants to the customer. These produced impressive tables, ranking the attributes that were necessary to achieve a successful project. Given the audience, it was no surprise that the language chosen by the worked example was Ada. For a short moment of seriousness here, the technique clearly had important lessons for large projects, but it is not clear how the many small shops developing embedded systems around the world could persuade the budget holders to fund such an analysis. It is also difficult to see how a company with limited expertise (or even a complete lack of expertise) in Language X can ever accept the conclusion that Language X is the right one for the project, or even factor Language X into the decision matrix.
But this all returns to the simple basis that there is no such thing as a perfect language. PL/1 was IBM’s attempt to create one, building on formal foundations a language for both scientific and commercial applications. It was a failure. Programming languages are tools, and, while most of us abuse the tools in our real toolboxes, we still know that the right solution exists for a problem. For many real-time, safety-critical systems, Ada, or one of the sub-sets, could be the right solution.
