Ada, Its Design, and the Language That Built the Languages

On Ada, the language that the Department of Defense built, the industry ignored, and every modern language quietly became

There is a language that made generics a first-class, standardised feature of a widely deployed systems language, formalised the package, built concurrency into the specification rather than the library, mandated the separation of interface from implementation, and introduced range-constrained types, discriminated unions, and a model of task communication that Go would arrive at, independently and by a different route, thirty years later. Successive revisions added protected objects, compile-time null exclusion, and language-level contracts. It is a language that Rust spent a decade converging toward from one direction while Python converged toward it from another, and that C# has been approximating, feature by feature, for the better part of two decades. It is a language that the industry has consistently described as verbose, arcane, and irrelevant. It is also, with a directness that embarrasses the usual story of software progress, the language that anticipated – with unusual precision – the safety features every modern language is now trying to acquire.

Ada is not famous. It is not the subject of enthusiastic conference talks or breathless blog posts. It does not have a charismatic founder who gives keynotes about the philosophy of programming, and it does not have a community that writes frameworks or publishes packages with clever names. What it has is a formal standard that has been revised four times since 1983; a presence in the software of many major commercial aircraft and avionics systems; a set of design decisions made under government contract in the late 1970s that the rest of the industry has spent forty years independently rediscovering; and a reputation, among the programmers who know it at all, as the language that says no – the language whose compiler enforces legality, visibility, typing, and a degree of safety checking that most languages leave to convention or tooling, that makes the programmer name what they mean, that treats ambiguity as an error rather than a feature. These qualities were, for a long time, considered its weaknesses. They are, on examination, the precise qualities that every language currently described as modern is attempting to acquire.

To understand why Ada exists requires understanding the particular crisis that produced it – a crisis not of computer science but of procurement, one that the United States Department of Defense encountered in the early 1970s when it attempted to survey the software that ran its weapons systems, logistics infrastructure, and command-and-control apparatus. What the survey found was not a software monoculture. It was the opposite: a proliferation of over four hundred and fifty distinct programming languages and dialects in active use across DoD systems, each one associated with a particular contractor or a particular era of development, none interoperable with any other, most unmaintainable by anyone except the original authors, many of those authors no longer available. The software that guided missiles could not be maintained by the people who maintained the software that navigated ships. The software that scheduled logistics could not share code with the software that processed communications. The languages had accumulated the way technical debt accumulates: invisibly, incrementally, each individual decision locally reasonable, the aggregate catastrophic.

The DoD's response was, for a government body, unusually sophisticated. Rather than simply mandating an existing language – COBOL, Fortran, and PL/1 were all considered and rejected – it undertook a requirements process that lasted five years and produced a series of documents of increasing precision: Strawman, Woodenman, Tinman, Ironman, and finally Steelman, each one refining and tightening the specification of what a DoD programming language must be. The Steelman document, issued in 1978, is a remarkable piece of engineering requirements literature: it does not specify a language, but describes the properties a language must have – properties derived from the actual failure modes of the DoD's existing software estate. It requires a module system with explicit separation of interface and implementation. It requires strong, static typing with no implicit conversions between types. It requires built-in support for concurrent tasks. It requires a consistent exception-handling mechanism. It requires that the language be machine-independent. It requires that programs be readable by people other than their authors. It requires that the language make program verification tractable. These were not aspirational preferences. They were requirements derived from the observed consequences of programs that lacked them.

In 1979, a competition among four finalists – teams designated Green, Red, Blue, and Yellow – produced a winner: the Green design, by a team led by Jean Ichbiah at CII Honeywell Bull in France. The winning design was named Ada, after Augusta Ada King, Countess of Lovelace, the nineteenth-century mathematician who wrote what is generally considered the first algorithm intended for mechanical computation. The choice of name was deliberate: the DoD wanted a name rather than an acronym, wanted to honour a woman in a field that had few women celebrated in it, and wanted to signal that the language was a statement of intent rather than a committee compromise. Ichbiah took the assignment seriously enough to accompany the standard with a rationale document – a full explanation of every design decision and the reasoning behind it – which is still, for anyone who reads it, one of the most lucid accounts in existence of what programming language design is actually for.

The centre of Ada's architecture is the package: a compilation unit consisting of a specification and a body, physically separate, with a relationship between them that the compiler enforces. The specification is the contract – it declares what the package provides: types, subprograms, constants, whatever the package makes available to the world. The body is the implementation – it provides the code that fulfills the contract. The specification is what client code sees. The body is invisible to client code and can be compiled independently, changed without recompilation of anything that depends only on the specification, and replaced entirely without any client knowing or caring. This separation is not a style recommendation. It is not enforced by a linter. It is a structural property of the language: client code that attempts to access anything not declared in the specification will not compile, because the compiler will not permit it to see the body. This is the module system that every language that came after Ada has been trying to build. Java's packages are not this: they are namespacing mechanisms with access modifiers, but the implementation is visible to reflection, to subclasses, and to code within the same package that may not have been anticipated. Python's modules are not this: they are files, with no formal separation between interface and implementation, no compiler to enforce the boundary. JavaScript's module system – introduced in 2015, thirty-two years after Ada's – provides import and export but no mechanism for a type to have a specification whose representation is hidden from importers. C's header files approximate the separation but without a compiler that can verify consistency between the header and the implementation or prevent the implementation's details from leaking through preprocessor macros. Go's exported identifiers – capitalised names are visible, lowercase names are not – achieve a related effect but without the formal specification-body distinction. Rust's module system with pub visibility rules is again an approximation. None of these is quite Ada's package system, because none of them makes the s