Some years ago, when anyone wanted to be rude about the Ada programming language, they would drag out the old saying about a camel being a horse designed by committee.

You remember Ada, don’t you? It was developed because the US Department of Defence (DoD), which spends a vast amount of money on software, was increasingly frustrated by dealing with hundreds of programming languages. (Anecdotally there were around 450 languages being used in the 1960s). DoD decided that it should use only a single language, and, cutting a long and complicated story short, after a series of competitions, DoD mandated that at least all embedded and real-time systems should use one language – by this time called Ada. Sadly, it was not a great success. In fact, in many people’s minds, it was a disaster.

Ada was launched in 1980 as MIL-STD-1815. (1815 was the year that Ada, Countess Lovelace, arguably the world’s first programmer, who provided support for Charles Babbage’s difference engine, was born.) In 1987, the mandate that Ada to be the only language used for specific DoD projects began to be enforced. Ten yeas later, in1997, the mandate was rescinded.

Ada is not a simple language. The early compilers were slow and buggy, and the run-time code often executed slowly. But Ada did not die. In fact, after a small dip, growth in Ada adoption has continued, and that is why we now have Ada 2012. And this is because Ada is, indeed, a camel designed by committee.

If you want to cross a desert, such as the sand deserts of North Africa, the high deserts of Central Asia, or even the plains of the Australian outback (where they have imported Afghan camels), camels are perfect pack beasts. They are not fast (except those bred specifically for camel racing), but they can walk for long periods of time without requiring much in the way of food and water, while they are carrying quite heavy loads. They can be unpleasant beasts and are notorious for their temper, especially if they are not treated well…

But perhaps you can complete the analogy to a programming language you know and love – or hate.

So – if your desert crossing is to build highly reliable systems for defence, aero-space, or other safety-critical systems, then perhaps you should look at Ada. And, over the last few years, Ada has quietly built a very strong niche in military and avionics systems, including air traffic control and railways, and it is even finding a role in financial systems. A list of some of the users of Ada can be found here — although, in September 2012, many of the links were not working.

Since the early days, compiler writers have learned how to create compilers that deliver tight and efficient code that comfortably executes at the speeds needed for real-time systems. There are now libraries and utilities. And, within the next few weeks, there should be Ada 2012.

What Ada 2012 does is build on the strengths of Ada. Right from the start (Ada 83) the language featured strong typing, packages, and support for concurrency and for real-time. Later releases added object orientation, dynamic dispatching, and protected types (Ada 95) and multiple inheritances of interfaces and container libraries (Ada 2005).

With Ada 2012 there are a number of further changes. There are two major changes. There is much better support for concurrency, linked with improvements for real-time operations, and the language now has the concept of dynamic contracts. Other changes are those needed to support these two innovations, to provide general improvements, and to tidy up loose ends and minor flaws in Ada 2005 that emerged after the standard was used in real-world applications.

Previously, Ada has supported multi-core architectures through a tasking model. Tasks are at a higher-level approach than the threads used in languages like C++ and Java, and they also incorporate a number of real-time concepts, such as setting timings for specific operations, providing for delays, and having the ability to abort a Task. Tasks are extended in Ada 2012, providing more flexibility in the timing of Tasks and the sequence in which Tasks are carried out. Also in Ada 2012, a Task can be specifically assigned to a processor or to a group of processors (a domain).

Dynamic contracts make the intention of the programmer clearer by making explicit some of the assumptions that are being made: effectively taking the idea of assertions, already in Ada 2005, and giving it more teeth. A sub-programme can have pre-conditions – things that must be correct if the sub-programme is to operate – and post-conditions -, conditions that must exist if the sub-programme has been successfully executed. One example might be when the programmer wants to Pop a stack. There has to be something within the stack to Pop, so a pre-condition would be that the stack is not empty, and a post-condition might be that the stack is not full, proving that a Pop has taken place.

Associated with contracts is the idea of type invariants – that all examples of a specific Type have certain properties that the programmer can be sure will not change – and Subtype predicates, which provide a closer definition of the members of a Subtype.

There is a raft of other changes, but many of these are probably of interest only to those who really want to get into the nuts and bolts. If that is you, then John Barnes, an Ada guru and member of the working parties for this and earlier versions of Ada, has written “A brief introduction to Ada 2012,” which, at just under a hundred pdf pages, is still a very readable and relaxed discussion, not just of the changes, but also of the rationale behind them. It can be found on the AdaCore website.

While AdaCore is a strong exponent of Ada  – Tucker Taft (see Does the World Need a New Programming Language?) spoke about Ada 2012 at Design East on September 18, 2012 – the company is not a lone voice in the wilderness. Atego, which bought Aonix, founded by Jean Ichbiah, “the father of Ada,” a couple of years ago, has just announced that it has now bought from IBM the IBM Rational Apex Ada Developer product family, including the Apex integrated development environment, to strengthen their Ada product line-up. And there is the work on SPARK, a subset of Ada that is designed for the most demanding of applications supported by Altran-Praxis.

So, if you are working on systems where safety and reliability are important, why wouldn’t you want to use Ada? The language is designed to help the programmer write good code, and the compilers are designed to back this up. One Ada evangelist says, “I regularly hear that the Ada compiler is a beast – it keeps finding lots of little issues. But the other side of this is that, when compiled, an Ada program will often run correctly the first time.”

The biggest barrier to wider Ada use is often cited as a lack of resources, or rather lack of bodies – there are not many programmers around who have Ada experience. And since, as we know, programmers don’t so much learn a language as embrace a religion, getting them to change languages can be an issue. However, companies deploying Ada claim that a good programmer can learn Ada and be writing very good quality code very quickly.

So, have a considered review of Ada for your next high-reliability or safety-critical project, please.

And, if you are not looking at Ada for your next high-reliability or safety-critical project, we would be really interested to know why. So please post your comments below.