Diff — Ada (programming language)

{{infobox

| title = Ada

| image = ada-lovelace.jpg

| caption = Ada King, Countess of Lovelace — the language's namesake and arguably the first computer programmer. Watercolor by Alfred Edward Chalon, c. 1840. Public domain.

| full_name = Ada

| designed_by = Jean Ichbiah (CII Honeywell Bull, Paris)

| developer = U.S. Department of Defense (HOLWG); ISO/IEC JTC1/SC22/WG9

| appeared = 1980 (MIL-STD-1815); 1983 (ANSI/MIL-STD-1815A)

| typing = Static, strong, nominative, safe

| paradigm = Multi-paradigm: structured, imperative, object-oriented (Ada 95+), concurrent, real-time, generic, contract-based (Ada 2012+)

| influenced_by = ALGOL 68, Pascal, Simula 67, CLU, Alphard, Mesa, LIS

| influenced = C++, Eiffel, Java, VHDL, Rust, SPARK, Chapel, PL/SQL

| latest = Ada 2022 (ISO/IEC 8652:2023, published May 2023)

| standard = MIL-STD-1815 (1980) → MIL-STD-1815A / ANSI (1983) → ISO 8652:1995 (Ada 95) → ISO 8652:2012 (Ada 2012) → ISO 8652:2023 (Ada 2022)

}}

**Ada** is the programming language that the United States Department of Defense built to save itself from itself. Designed in the late 1970s by **Jean Ichbiah** and his team at CII Honeywell Bull in Paris, mandated by Congress for all defense software, and named after **[[Ada Lovelace]]** — the 19th-century mathematician widely regarded as the first computer programmer — Ada is the most ambitious language standardization effort ever undertaken by a government. It was born from a crisis: the DoD was spending over three billion dollars a year on software, using more than **450 different programming languages and dialects**, and watching its weapons systems drown in bugs, cost overruns, and maintenance nightmares.

Ada's response to that crisis was radical: build a single language that is safe by design, readable by default, concurrent by nature, and strong-typed to the point where entire categories of bugs cannot exist. Enforce it with a compiler validation regime so strict that no implementation can call itself "Ada" without passing thousands of conformance tests. Then mandate its use across the largest military organization on Earth.

It worked — imperfectly, controversially, and at enormous cost — but the software that Ada produced is still flying combat aircraft, controlling missile defense systems, managing air traffic, and running subway trains in 2026. The Boeing 777's avionics are 99.9% Ada. The F-22 Raptor's mission software is Ada. The Eurofighter Typhoon, the JAS 39 Gripen, the C-130J, the AH-64 Apache, the Paris Métro — all Ada. No other programming language has been so deliberately engineered for the specific purpose of keeping people alive.

---

[[File:pentagon-aerial.jpg|right|280px|The Pentagon — headquarters of the Department of Defense that commissioned Ada. U.S. government work, public domain.]]

By the mid-1970s, the Department of Defense had a software problem of staggering scale. Each military branch — Army, Navy, Air Force, Marines — developed its own software using its own preferred languages, its own toolchains, its own conventions. A 1974 study commissioned by the Director of Defense Research and Engineering, Malcolm R. Currie, revealed the extent of the chaos: the DoD was using an estimated **450 different programming languages and dialects** across its embedded systems, weapons platforms, and command-and-control infrastructure[1].

The costs were astronomical. In 1975, the DoD was spending over **$3 billion per year** on software — a figure that was growing faster than the defense budget itself. More alarming than the raw cost was the trajectory: maintenance consumed a larger share every year, new systems were delivered late and over budget, and the lack of standardization meant that skills, tools, and code were not portable between projects. A programmer trained on one missile system's software was useless on another's. A testing tool built for one avionics suite could not be used on the next. The fragmentation was not just inefficient — it was dangerous[2].

```fact

The DoD software crisis was not unique — the broader "software crisis" had been named at the 1968 NATO Software Engineering Conference — but the military version was worse than most because of the sheer scale and the life-or-death consequences. In commercial software, a bug means a crash or a lost sale. In weapons software, a bug means a missile that hits the wrong target, a fighter jet that loses control, or an air defense system that fails to detect an incoming threat.

```

The specific languages in use across the DoD included JOVIAL (Air Force), CMS-2 (Navy), TACPOL (Army), SPL/I (various), plus countless assembly dialects and one-off domain-specific languages. Each service branch had its own favorites. The Army's missile software was written in a different language than the Air Force's fighter avionics, which was different from the Navy's submarine sonar systems. Software engineers trained on one weapons program could not easily transfer to another. The problem was not that these languages were bad — many were competent for their specific purpose — but that the sheer number of them made the entire enterprise unmaintainable.

The broader context was the "software crisis" that the computing industry had been wrestling with since the 1968 NATO Software Engineering Conference in Garmisch, Germany. That conference recognized that software was growing faster than our ability to engineer it reliably. Hardware was advancing exponentially; software quality was stagnant or declining. Projects ran over budget, were delivered late, and failed in the field. The DoD, as the world's largest software customer, felt every dimension of the crisis at scale.

The response was institutional: in 1975, the **Higher Order Language Working Group (HOLWG)** was chartered under the Office of the Secretary of Defense to solve the problem. The group was led initially by **Col. William Whitaker**, a visionary Air Force officer who would become the driving force behind Ada's development. The HOLWG's mandate was to formulate requirements for a single common programming language suitable for all DoD embedded systems, evaluate existing languages against those requirements, and if no existing language met the requirements, design a new one.

---

The HOLWG proceeded with extraordinary methodological rigor. Rather than designing a language and hoping it would meet the DoD's needs, they first defined what the language needed to do — and then designed the language to meet those requirements. The requirements evolved through a series of progressively refined documents, each named after a progressively harder material:

| Document | Date | Purpose |

|---|---|---|

| **Strawman** | 1975 | Initial brainstorming — broad, informal requirements |

| **Woodenman** | 1975 | First formal requirements document |

| **Tinman** | 1976 | Refined requirements after community review |

| **Ironman** | 1977 | Near-final requirements; used to evaluate existing languages |

| **Steelman** | June 1978 | Final requirements — the specification the winning language had to satisfy |

Each iteration was distributed for review not just within the DoD but to the entire international computing community — universities, NATO allies, industry, and standards bodies. The process was deliberately open and deliberately exhaustive. The Steelman document specified requirements covering:

- **Data types**: strong typing, user-defined types, range constraints

- **Control structures**: structured programming, exception handling

- **Modular decomposition**: packages, information hiding, separate compilation

- **Real-time support**: tasking, interrupt handling, timing constraints

- **Reliability**: compile-time checking, run-time constraint checking, no undefined behavior where avoidable

- **Maintainability**: readability, self-documentation, portability

- **Efficiency**: no feature that could not be efficiently implemented on contemporary hardware

```quote

The HOLWG's requirements process was, in retrospect, one of the most disciplined language design efforts in computing history. They evaluated 23 existing languages against the Steelman requirements — including Pascal, PL/I, [[ALGOL]] 68, [[FORTRAN]], [[COBOL]], Jovial, and CMS-2 — and concluded that no existing language could meet them. A new language was necessary.

```

---

In 1977, the HOLWG funded four contractor teams to design candidate languages, each identified by a color:

| Color | Team | Based on |

|---|---|---|

| **Red** | Intermetrics (Benjamin Brosgol) | ALGOL 68 |

| **Blue** | SofTech (John Goodenough) | Pascal |

| **Green** | CII Honeywell Bull (Jean Ichbiah) | Pascal / LIS |

| **Yellow** | SRI International (Jay Spitzen) | ALGOL 68 |

The first-phase evaluation, in 1978, eliminated Yellow and Blue. Red and Green advanced to the second phase. Both teams refined their designs against the Steelman requirements and submitted final proposals.

The competition was conducted with unusual transparency. Each team received the same Steelman requirements, the same evaluation criteria, and the same access to DoD reviewers. The designs were evaluated by a panel that included academic computer scientists, military software engineers, and industry practitioners. The evaluation criteria weighted reliability and maintainability more heavily than raw performance — a deliberate reflection of the DoD's experience that software maintenance costs exceeded development costs by a factor of three or more.

In April 1979, the **Green** language was selected. The winning design was led by **Jean Ichbiah**, a French computer scientist at CII Honeywell Bull in Paris. Ichbiah was not an obvious choice for a DoD language designer — he was a civilian, European, and had previously designed a relatively obscure systems implementation language called LIS. But his design was technically superior: it met the Steelman requirements more completely than Red, had a cleaner type system, and integrated concurrency more naturally.

The winning language was named **Ada**, after Augusta Ada King, Countess of Lovelace — [[Ada Lovelace]] — the 19th-century mathematician who wrote what is widely considered the first computer program, an algorithm for Charles Babbage's Analytical Engine, in 1843. The naming was approved by the DoD in 1979 and ratified by Ada Lovelace's descendants. Ichbiah's Green design was not merely incrementally better than Red — it was architecturally different. Green's package system, its approach to strong typing with derived types and subtypes, and its integration of tasking into the language core reflected a coherent design philosophy. Red, while technically competent, was more complex and less unified. The evaluators concluded that Green better satisfied the Steelman requirements and would be more maintainable in the long term[3].

Ichbiah later reflected on the design process in interviews. He emphasized that Ada was not designed as an academic exercise or a research language. It was designed to solve a practical, operational problem: the DoD's software crisis. Every feature was evaluated against the question: "Will this reduce defects, reduce costs, and improve maintainability in large, long-lived, mission-critical systems?" Features that did not pass this test were excluded, no matter how intellectually interesting they were. This discipline is why Ada has so few "cute" features compared to languages like Haskell or Scala — and why the features it does have are so thoroughly thought through.

---

The Ada language was published as **MIL-STD-1815** in December 1980 — the military standard number chosen deliberately: **1815** is the year Ada Lovelace was born.

The revised standard, **MIL-STD-1815A** (also ANSI/MIL-STD-1815A), was published in **February 1983** after an intensive international review process. Ichbiah's team had to process over **7,000 comments** from experts in 15 countries. The resulting specification was 589 pages long — among the most detailed programming language standards ever written.

The standard was simultaneously adopted as an ANSI standard, making Ada the first programming language to be both a military standard and an ANSI standard from the outset. This dual status was deliberate: Ada was designed for the military, but the DoD wanted it to be viable for civilian use as well, to broaden the compiler market and reduce costs.

```fact

The MIL-STD-1815 number — 1815 — is one of the most deliberate acts of symbolism in the history of computing. Ada Lovelace was born on December 10, 1815, the daughter of the poet Lord Byron and the mathematician Annabella Milbanke. By naming both the language and the standard number after her, the DoD linked the most ambitious government software project in history to the origin of programming itself. The standard number was proposed by Lt. Col. William Whitaker, who led the HOLWG effort through its formative stages.

```

---

The DoD did not merely recommend Ada — it **mandated** it by law. The Ada mandate evolved through several directives:

- **DoD Directive 5000.29** (1976) — required that new defense systems use DoD-approved higher-order languages

- **DoD Directive 3405.1** (April 2, 1987) — established Ada as the single, common programming language for all defense computer resources used in intelligence, command and control, or weapons systems

- **Section 8084, FY 1991 Defense Appropriations Act** (Public Law 101-511, signed November 5, 1990) — Congress **enacted into law** the requirement that DoD software be written in Ada

- **Section 9070, FY 1993 Defense Appropriations Act** (Public Law 102-396, signed October 6, 1992) — the definitive wording:

> *"Notwithstanding any other provisions of law, where cost effective, all Department of Defense software shall be written in the programming language Ada, in the absence of special exemption by an official designated by the Secretary of Defense."*

This was not a guideline or a recommendation. This was a federal law enacted by the United States Congress, requiring the largest military organization in the world to write its software in a single programming language. No other language in history has ever received this kind of institutional backing[4].

The mandate was controversial from the start. Critics argued that forcing Ada on projects where other languages were better suited — database systems, quick prototypes, scientific computing — increased costs rather than reducing them. Defenders argued that the long-term savings from standardization, tool sharing, and maintainability justified the short-term costs. The debate was never fully resolved: the mandate was effectively relaxed by a 1997 memorandum from the Assistant Secretary of Defense, and formally canceled in 1998. By then, Ada had been established in all the systems where it mattered most.

---

The DoD did not merely design a language — it built an **enforcement infrastructure** unlike anything the software industry had seen. The **Ada Compiler Validation Capability (ACVC)** was a suite of thousands of test programs that every compiler had to pass before it could legally be called an "Ada compiler" and used on DoD contracts.

The ACVC tested every clause of the language standard. There were **Class A** tests (legal programs that must compile and execute correctly), **Class B** tests (illegal programs that must be rejected by the compiler), **Class C** tests (programs that test compile-time restrictions), and **Class L** tests (linker-level tests). A compiler that passed the entire suite was issued a **Validation Certificate** by the Ada Validation Organization (AVO), part of the Ada Joint Program Office. The certificate was valid for one year and tied to a specific compiler version, host platform, and target platform.

This regime had profound consequences:

**Positive**: Every validated Ada compiler was guaranteed to accept the same programs and produce the same behavior. Portability was not a hope — it was a tested, certified fact. No other programming language has ever achieved this level of cross-compiler consistency.

**Negative**: The cost of validation was enormous — hundreds of thousands of dollars per compiler configuration. This created a barrier to entry that limited the Ada compiler market to a handful of large vendors (Alsys, Rational, Verdix, DDC-I, Green Hills). Small, innovative compiler efforts could not afford validation. The market remained expensive and concentrated.

**Perverse**: Some compiler vendors optimized for passing the ACVC rather than for generating good code. A compiler could be "validated" and still produce slow executables, because the tests measured conformance, not performance. This contributed to Ada's early reputation as a slow language — a reputation that was largely undeserved by the 1990s but persisted for decades.

The validation regime was eventually replaced by the Ada Conformity Assessment Authority (ACAA) and the Ada Conformity Assessment Test Suite (ACATS), which operates under ISO/IEC procedures rather than military ones. The principle remains: you cannot claim to implement Ada without proving it.

The validation system had one lasting positive legacy that is easy to overlook: it established the principle that **compiler correctness is a testable property**. Before Ada, compiler vendors tested their products informally. After Ada, the idea that a compiler must pass a standardized test suite became the norm. GCC's test suite, LLVM's test infrastructure, and the extensive conformance testing in modern JavaScript engines all owe something to the precedent that Ada's ACVC established.

---

Ada is immediately recognizable by its verbosity, its strong typing, and its English-like keywords. Where C uses `{` and `}`, Ada uses `begin` and `end`. Where C allows implicit type conversions, Ada requires explicit ones. Where C's compiler accepts almost anything and lets the programmer discover bugs at runtime, Ada's compiler rejects programs that violate the language's safety rules at compile time.

```ada

with Ada.Text_IO;  use Ada.Text_IO;

procedure Hello is

begin

   Put_Line ("Hello, world!");

end Hello;

```

More representative — a strongly-typed, range-constrained program:

```ada

with Ada.Text_IO;  use Ada.Text_IO;

procedure Temperature is

   type Celsius is digits 6 range -273.15 .. 1_000_000.0;

   type Fahrenheit is digits 6 range -459.67 .. 1_800_032.0;

   function To_Fahrenheit (C : Celsius) return Fahrenheit is

   begin

      return Fahrenheit (C * 9.0 / 5.0 + 32.0);

   end To_Fahrenheit;

   Boiling : constant Celsius := 100.0;

begin

   Put_Line ("Boiling point: " & Fahrenheit'Image (To_Fahrenheit (Boiling)) & " F");

end Temperature;

```

The `Celsius` and `Fahrenheit` types are distinct — you cannot accidentally pass a Fahrenheit value where a Celsius is expected, even though both are floating-point numbers. The range constraint (`-273.15 .. 1_000_000.0`) means that the compiler and runtime will reject any value outside absolute zero or the upper bound. The underscore in `1_000_000.0` is a digit separator — Ada had this decades before C23 adopted it.

Ada's module system uses **packages** — a concept that influenced Java's packages, C#'s namespaces, and virtually every modern module system. A package has a visible **specification** (the interface) and a hidden **body** (the implementation):

```ada

package Stack is

   procedure Push (Item : in Integer);

   procedure Pop  (Item : out Integer);

   function  Is_Empty return Boolean;

end Stack;

package body Stack is

   Max : constant := 100;

   Data : array (1 .. Max) of Integer;

   Top  : Natural := 0;

   procedure Push (Item : in Integer) is

   begin

      Top := Top + 1;

      Data (Top) := Item;

   end Push;

   procedure Pop (Item : out Integer) is

   begin

      Item := Data (Top);

      Top  := Top - 1;

   end Pop;

   function Is_Empty return Boolean is

   begin

      return Top = 0;

   end Is_Empty;

end Stack;

```

This separation of specification and body is not optional — it is the language's fundamental organizational principle. The compiler enforces it. You cannot access `Data` or `Top` from outside the package body. Information hiding is not a convention in Ada; it is a rule.

Ada has **native language-level concurrency** — tasks are first-class citizens of the language, not library additions. This was radical in 1983 and is still unusual in 2026:

```ada

task type Sensor_Reader is

   entry Read (Value : out Float);

end Sensor_Reader;

task body Sensor_Reader is

   Current : Float := 0.0;

begin

   loop

      -- Read from hardware...

      Current := Current + 0.1;

      accept Read (Value : out Float) do

         Value := Current;

      end Read;

   end loop;

end Sensor_Reader;

```

The `accept` statement implements a **rendezvous** — a synchronization mechanism where the task waits for a caller and exchanges data atomically. This is more expressive and more analyzable than raw threads and mutexes, which is why Ada's concurrency model has been adopted in safety-critical real-time systems where deterministic timing is a life-or-death requirement.

Ada introduced structured exception handling to mainstream programming (along with CLU, which influenced it):

```ada

begin

   Open (File, In_File, "data.txt");

   -- process file...

exception

   when Name_Error =>

      Put_Line ("File not found.");

   when others =>

      Put_Line ("Unexpected error.");

end;

```

Ada's exceptions are objects, not integers or strings. They carry information, propagate up the call stack, and can be handled at any level. This model directly influenced C++, Java, C#, and Python's exception handling.

---

Ada's type system is the strongest in any mainstream programming language. Every type is distinct. Every constraint is checked. Every conversion is explicit.

```ada

type Miles is new Float;

type Kilometers is new Float;

Distance_UK : Miles := 100.0;

Distance_EU : Kilometers := 160.0;

-- Distance_UK := Distance_EU;  -- COMPILE ERROR: type mismatch

```

This is not an alias — `Miles` and `Kilometers` are genuinely different types, even though both are floating-point numbers. You cannot mix them without an explicit conversion. This single feature would have prevented the **Mars Climate Orbiter failure** in 1999, where a Lockheed Martin module produced thruster impulse data in pound-force seconds while NASA's software expected newton-seconds — a unit confusion that caused a $327 million spacecraft to burn up in the Martian atmosphere. In Ada, the compiler would have caught this at build time.

```ada

subtype Day_Number is Integer range 1 .. 31;

subtype Probability is Float range 0.0 .. 1.0;

Today : Day_Number := 15;     -- OK

-- Today := 42;               -- CONSTRAINT_ERROR at runtime (or compile time if provable)

```

Every assignment, every parameter pass, every arithmetic result can be range-checked. The runtime catches violations immediately rather than allowing corrupted data to propagate silently — the behavior that causes the most dangerous bugs in C programs.

```ada

type Traffic_Light is (Red, Amber, Green);

type Suit is (Hearts, Diamonds, Clubs, Spades);

```

Ada's enumerations are strong types — `Red` and `Hearts` are completely different values, even if they have the same underlying representation. C's enumerations are just integers in disguise. Ada's are genuine types.

```fact

Ada's type system directly influenced [[Rust_(programming_language)|Rust]]'s approach to type safety. Rust's `enum` with data-carrying variants, its strict type distinctions, its lack of implicit conversions, and its philosophy of "if it compiles, it works" all echo Ada's design principles from forty years earlier. When Graydon Hoare listed Ada's influences on Rust, he cited Mesa, Hermes, and CLU — languages from the same era and tradition as Ada. The lineage is clear.

```

---

Ada has been standardized four times, each revision adding significant capabilities while maintaining backward compatibility:

The original standard: packages, strong typing, generics, tasking, exceptions, separate compilation, representation clauses for hardware access. A complete, production-ready language from day one — unlike many languages that ship minimal and grow incrementally, Ada 83 was designed to be complete.

The first ISO revision. Ada 95 was the **first internationally standardized object-oriented language** (beating Java and C++ to ISO standardization). Key additions:

- **Object-oriented programming** — tagged types with inheritance and dispatching (dynamic polymorphism)

- **Protected objects** — a concurrency primitive that encapsulates shared data with automatic mutual exclusion, cleaner than raw mutexes

- **Hierarchical libraries** — child packages for modularity at scale

- **The Distributed Systems Annex** — language-level support for distributed computing

- **Modular types** — unsigned integer types with wrap-around arithmetic (replacing the need for unsafe bit-level hacks)

Ada 95 was led by **Tucker Taft** of Intermetrics (later AdaCore), who would continue to lead Ada language evolution for three decades.

Incremental refinement: interfaces (multiple inheritance of specification), improved containers library, improved access types, enhanced real-time support.

The most important revision since the original. Ada 2012 introduced **contract-based programming** as a first-class language feature:

- **Preconditions** (`Pre` aspect) — what must be true before a subprogram is called

- **Postconditions** (`Post` aspect) — what the subprogram guarantees after execution

- **Type invariants** — properties that must hold for all externally visible values of a type

- **Subtype predicates** — arbitrary constraints on subtypes

```ada

function Sqrt (X : Float) return Float

   with Pre  => X >= 0.0,

        Post => Sqrt'Result >= 0.0 and then

                abs (Sqrt'Result ** 2 - X) < 0.001;

```

This contract tells the compiler, the runtime, and the formal verification tools exactly what `Sqrt` requires and guarantees. It is documentation, testing, and formal specification in a single syntax. This feature directly influenced Rust's ongoing explorations of contracts and was a major upgrade for the SPARK formal verification toolset.

The current standard (published May 2023, despite the "2022" name). Key additions:

- **Parallel constructs** — `parallel for` and `parallel do` for safe, structured parallelism

- **Light-weight iteration** — simpler syntax for container iteration

- **Improved contracts** — delta aggregates, extended expressions

- **Image attribute for all types** — `'Image` works on composite types

- **Jorvik profile** — a relaxed version of the Ravenscar profile for less constrained real-time systems

Ada 2022 demonstrates that the language is still actively evolving — ISO/IEC 8652 was marked "to be revised" in September 2025, indicating that work on the next revision has already begun.

---

**[[SPARK_Ada|SPARK]]** is a formally verifiable subset of Ada, developed by Altran (now Capgemini Engineering) and AdaCore. It is not a separate language — it is Ada with restrictions that make formal verification tractable, plus a toolset (**GNATprove**) that can mathematically prove properties of the code. See the full [[SPARK_Ada|SPARK article]] for the complete history, deployments, and technical details.

SPARK eliminates features that make verification undecidable — aliasing, unchecked access, uncontrolled side effects — and adds flow analysis (proving that every variable is initialized before use, that every output depends only on declared inputs) and functional verification (proving that the code satisfies its contracts).

| Property | What SPARK proves |

|---|---|

| Absence of runtime errors | No buffer overflow, no division by zero, no range violation, no integer overflow |

| Data flow correctness | Every variable initialized before use; no unintended data dependencies |

| Information flow correctness | No information leakage between security domains |

| Functional correctness | The code satisfies its pre/postconditions and type invariants |

SPARK has been used in:

- **MULTOS** — the high-security smart card operating system (UK's CESG — now NCSC — certified to ITSEC Level E6, the highest commercial security evaluation ever achieved)

- **UK military aircraft** — the Eurofighter Typhoon's secondary flight controls

- **Paris Métro Line 14** — driverless train control software (RATP, certified to the highest railway safety level, SIL 4)

- **Lunar lander software** — Masten Space Systems' XL-1 lander used SPARK for mission-critical flight control

- **Cross-domain solutions** — military systems that must provably prevent information leakage between classification levels

```fact

The Paris Métro Line 14 is a driverless, fully automated railway. Its signaling and control software, written in SPARK, was formally verified to prove the absence of runtime errors. The system has operated since 1998 with an extraordinary safety record. Every day, millions of Parisians trust their lives to software that has been mathematically proven correct — in a language designed for the Pentagon.

```

---

Ada's most important deployment is in military avionics and weapons systems. A partial list of systems that use Ada:

- **F-15 Eagle** — mission computer software

- **F-16 Fighting Falcon** — Modular Mission Computer OFP (~800,000 lines of Ada)

- **F/A-18 Hornet** — mission systems

- **F-22 Raptor** — mission software and sensor fusion

- **Eurofighter Typhoon** — avionics and flight control

- **JAS 39 Gripen** — avionics

- **Dassault Rafale** — mission systems

- **AH-64 Apache** — helicopter avionics

- **C-130J Super Hercules** — mission computer

- **C-17 Globemaster III** — avionics

- **Boeing 777** — 99.9% of avionics software (the most Ada-intensive commercial aircraft ever built)

The Boeing 777 story deserves elaboration. When Boeing designed the 777 in the early 1990s, it insisted that **all suppliers** write their avionics software in Ada. This was not a DoD mandate — Boeing is a commercial aircraft manufacturer — but a deliberate engineering decision. According to Brian Pflug, Boeing's engineering avionics software manager, the rationale was portability, safety, and long-term maintainability.

Not all suppliers were happy. Honeywell conducted an extensive comparison of Ada versus C for the project and concluded that Ada's built-in safety features — strong typing, runtime constraint checking, exception handling — would translate into less time and expense debugging. Hydro-Aire used Alsys Ada compilers for the brake control system. Smiths Industries used Ada for the Primary Flight Display. Across the entire aircraft, 99.9% of the avionics code was Ada — representing millions of lines and one of the largest Ada deployments in civilian history.

The 777's success was a powerful argument for Ada outside the military. If the world's most advanced commercial aircraft could be built on Ada, the language was clearly viable for any safety-critical project. The 777 remains in production in 2026 (as the 777X), and its avionics architecture — rooted in Ada — continues to fly[6].

- **Patriot** missile defense system

- **Standard Missile** (SM-2, SM-3, SM-6)

- **Tomahawk** cruise missile

- **Naval tactical systems** — Aegis Combat System components

- **THAAD** — Terminal High Altitude Area Defense

- **International Space Station** — ISS flight control software components

- **NASA Goddard Space Flight Center** — flight dynamics systems

- **European Space Agency** — various satellite and mission systems

- **Masten Space Systems** — XL-1 lunar lander flight control (SPARK)

- **NATS** (UK air traffic control) — several systems

- **Thales** — air traffic management systems worldwide

- **NavCanada** — Canadian air traffic control

- **Paris Métro Line 14** — driverless signaling (SPARK, SIL 4)

- **London Docklands Light Railway** — signaling

- **Various European railway signaling systems** — certified to EN 50128 / SIL 3-4

```quote

"Ada is the programming language that helped build the mainstay of the Air Force or Navy, as it is used on combat aircraft programs such as the F-15 Eagle, the F-16 Fighting Falcon, the F-18 Hornet and the F-22 Raptor. It is also used in many other allied programs such as the Eurofighter Typhoon or the JAS 39 Gripen. Beyond combat aircraft, it is used on many other military programs such as the C-130J and C-17 airlifters, the AH-64 Apache helicopter and many more." — AdaCore, "Developing Military Grade Software"

```

---

On June 4, 1996, the maiden flight of the **Ariane 5** rocket ended 40 seconds after launch when the vehicle veered off course, broke apart, and self-destructed. The payload — four Cluster scientific satellites — was lost. The total cost was approximately **$500 million**, uninsured.

The cause was a software error in the Inertial Reference System (SRI). A 64-bit floating-point value representing horizontal velocity bias was converted to a 16-bit signed integer. On Ariane 4 (which used the same software), this value never exceeded the 16-bit range. On Ariane 5, which flew a faster trajectory, the value overflowed. The overflow triggered an exception. The exception was not caught — the handler had been deliberately omitted as a "design decision" to save resources — and the SRI crashed. The backup SRI, running identical software, crashed simultaneously. The flight control computer, receiving garbage data, commanded full nozzle deflection. The rocket broke apart.

The SRI software was written in Ada. But the Ariane 5 disaster is not an Ada failure — it is a **requirements failure** and a **testing failure**. The software worked exactly as specified: it converted the value, the value overflowed, Ada's runtime raised `CONSTRAINT_ERROR` (exactly as the language requires), and the handler was absent (a deliberate decision). The bug was that nobody tested the Ariane 4 software against Ariane 5's flight profile.

The lessons are important:

1. **Ada caught the error** — it raised an exception rather than silently producing garbage data (which is what C would have done). The problem was not that Ada detected the error but that no handler was present.

2. **Code reuse without re-verification is dangerous** — the SRI software was "reused" from Ariane 4 without testing against the new rocket's trajectory.

3. **Formal verification would have caught it** — a SPARK analysis of the conversion would have flagged the potential overflow at compile time.

The Ariane 5 disaster remains one of the most studied software failures in history. It demonstrates both Ada's strength (runtime detection of overflow) and the limits of any programming language (you cannot prevent requirements errors with type checking alone).

---

The Ada mandate's history is a case study in the limits of institutional force applied to technology adoption:

**The peak (1983–1995)**: Ada was the law. New weapons systems used Ada. Compiler vendors invested billions in Ada toolchains. Universities taught Ada. The Ada Joint Program Office (AJPO) managed the language, maintained the compiler validation suite, and enforced the mandate. Ada was, for a decade, the most important programming language in the world's largest technology customer.

**The backlash (1990s)**: The mandate generated enormous resentment. Projects that did not need Ada's safety features — database applications, web services, quick prototypes — were forced to use it anyway, at significant cost. The compiler validation regime, while ensuring quality, also limited the market: only validated compilers could be used, and validation was expensive. Meanwhile, C, C++, and later Java were cheaper, more widely known, and had larger tool ecosystems. The rise of commercial-off-the-shelf (COTS) software further weakened the case for a DoD-specific language.

**The relaxation (1997)**: The Assistant Secretary of Defense for Command, Control, Communications, and Intelligence issued a memorandum relaxing the mandate: projects could use any language, with Ada as the "preferred" choice for mission-critical systems but no longer the required one.

**The formal end (1998)**: DoD Directive 3405.1 was replaced. Ada was no longer mandated. Projects were free to choose their programming language based on technical merit and cost.

**The cost debate**: Studies conducted during the mandate era produced contradictory results. Some found that Ada projects had lower defect rates and lower lifecycle costs than equivalent C or [[FORTRAN]] projects. Others found that Ada's higher compiler costs, longer compilation times, and steeper learning curves increased development costs. The truth likely depended on the domain: for large, long-lived, safety-critical systems, Ada's upfront costs were amortized over decades of maintenance. For small, short-lived, or research-oriented projects, Ada's overhead was pure waste.

**The aftermath**: Paradoxically, the end of the mandate did not kill Ada. It killed Ada *adoption in systems that didn't need it* — which is exactly what Ada's critics had wanted. In the systems where Ada's safety features genuinely mattered — avionics, missile defense, air traffic control — teams continued to choose Ada voluntarily, because the language's strengths in those domains were real, not political. The F-22, the C-130J, the Boeing 777, the Paris Métro — all chose Ada or continued with Ada after the mandate ended.

---

The Ada ecosystem was transformed in the 1990s by **GNAT** — the GNU NYU Ada Translator, initially developed at New York University under a contract from the U.S. Air Force. GNAT was the first production Ada compiler built on GCC, and it was free software under the GPL.

**AdaCore**, founded in 1994 by several GNAT developers (including Robert Dewar and Edmond Schonberg), became the primary commercial steward of GNAT. AdaCore offers GNAT Pro (a commercially supported version with enhanced tooling), SPARK Pro (the formal verification toolset), and a growing suite of analysis tools.

In 2021, AdaCore released a **Community Edition** of GNAT, making a full Ada development environment freely available. This was a strategic shift: Ada's biggest barrier to adoption had long been the cost and limited availability of compilers. With GNAT CE and the Alire package manager (Ada's answer to Cargo or pip), modern Ada development is accessible to anyone.

---

Ada is experiencing a quiet renaissance, driven by the same forces that propelled [[Rust_(programming_language)|Rust]]: the global recognition that memory-unsafe languages are a critical security risk.

In 2022, the U.S. National Security Agency published a cybersecurity information sheet recommending "memory-safe languages" — and explicitly listed Ada alongside Rust, Java, C#, Go, and Swift. The White House Office of the National Cyber Director followed in 2024 with a report calling for the same. In 2026, AdaCore reported "a significant increase in design wins across US aerospace and defense programs" using Ada and SPARK[5].

The convergence of Ada and Rust is particularly striking. Both languages share core philosophical commitments: strong static typing, no implicit conversions, compile-time safety guarantees, deterministic resource management, and the principle that the compiler should catch errors rather than leaving them for the programmer to discover at runtime. Rust's borrow checker is a more sophisticated mechanism than Ada's access type rules, but the goal is the same — preventing memory errors at compile time. The two languages are increasingly seen as complementary rather than competitive: Ada for the deeply embedded, safety-certified, long-lifecycle systems; Rust for newer systems and application-level code where a larger ecosystem matters.

The irony is exquisite: Ada has been memory-safe since 1983. The language that the DoD mandated — and that the industry spent two decades resenting — turns out to have been right about the most important software engineering question of the era. While C and C++ developers are now scrambling to retrofit safety through static analyzers, sanitizers, and coding standards, Ada programs written in 1985 were already safe.

```fact

A 2026 VDC Strategy survey of over 500 embedded software decision-makers ranked Ada, SPARK, and Rust as the three best languages for meeting safety and security requirements. 85% of engineers reported that programming language choice directly impacts safety and security. Ada's steadily increasing adoption was noted as a distinguishing trend: while some languages declined, Ada continued to grow in safety-critical applications.

```

---

Ada had **generics** in 1983 — a decade before C++ templates were standardized, two decades before Java added generics, and three decades before Go added them. Generics allow writing code that works for any type, without sacrificing type safety:

```ada

generic

   type Element is private;

package Generic_Stack is

   procedure Push (Item : in Element);

   procedure Pop  (Item : out Element);

   function  Is_Empty return Boolean;

end Generic_Stack;

```

To use it:

```ada

package Int_Stack is new Generic_Stack (Element => Integer);

package Str_Stack is new Generic_Stack (Element => String);

```

Each instantiation creates a fully type-checked, specialized version. There is no "duck typing," no runtime type erasure, and no unchecked casts. The compiler verifies that the actual type satisfies the generic's requirements at instantiation time — not at use time (as in C++ templates, where errors can be cryptic and appear deep in the template implementation).

Ada's generic formal parameters go beyond simple type parameters. You can parameterize on:

- Types (private, limited, tagged, abstract)

- Subprograms (pass a function or procedure as a generic parameter)

- Packages (parameterize on an entire module)

- Values (compile-time constants)

This expressiveness makes Ada generics more powerful than Java's generics (which are erased at runtime) and more disciplined than C++ templates (which are essentially unconstrained text substitution until concepts were added in C++20). The design directly influenced Eiffel's generics and, through Eiffel, shaped the concepts that would eventually appear in C++ and Rust's trait bounds.

---

One of Ada's most distinctive features is its ability to describe the exact binary layout of data structures — crucial for embedded systems, hardware registers, and network protocols:

```ada

type Status_Register is record

   Ready    : Boolean;

   Error    : Boolean;

   Mode     : Integer range 0 .. 3;

   Reserved : Integer range 0 .. 15;

end record;

for Status_Register use record

   Ready    at 0 range 0 .. 0;

   Error    at 0 range 1 .. 1;

   Mode     at 0 range 2 .. 3;

   Reserved at 0 range 4 .. 7;

end record;

for Status_Register'Size use 8;

```

This tells the compiler exactly which bits in a byte correspond to which fields. The `at 0 range 2 .. 3` means "bits 2 and 3 of the byte at offset 0." The `'Size use 8` pragma ensures the entire record fits in exactly one byte.

Representation clauses extend to specifying byte order (`Bit_Order`), alignment (`'Alignment`), and size (`'Size`) for any type. Ada 2012 and 2022 added further refinements, including aspect-based syntax that makes representation specifications cleaner and more composable.

This capability means Ada can replace assembly language for hardware access — not approximately, not with unsafe casts, but precisely, portably, and type-safely. C can do this too, but with bit-fields whose layout is implementation-defined (the standard does not specify bit ordering). Ada's representation clauses are fully specified by the programmer, not left to the compiler's discretion.

---

The language's naming deserves more than a footnote. **Augusta Ada King, Countess of Lovelace** (1815–1852) was the daughter of the poet Lord Byron and the mathematician Annabella Milbanke. Tutored in mathematics from childhood — partly to counteract what her mother feared was the Byron madness — she became fascinated by Charles Babbage's proposed Analytical Engine, a mechanical general-purpose computer that was never built.

In 1843, Ada Lovelace translated an Italian article about the Analytical Engine by Luigi Menabrea and added her own extensive notes — labeled Notes A through G. **Note G** contained an algorithm for computing Bernoulli numbers on the Analytical Engine. This algorithm is widely recognized as the **first computer program** ever written — and its author as the first programmer.

Lovelace also grasped something that Babbage himself did not fully articulate: the machine was not merely a calculator. She wrote:

```quote

"The Analytical Engine weaves algebraical patterns just as the Jacquard loom weaves flowers and leaves." — Ada Lovelace, Note A, 1843

```

This insight — that a computing machine could manipulate symbols, not just numbers — anticipates the fundamental insight of computer science itself, a century before Turing and von Neumann formalized it.

When the HOLWG needed a name for the language in 1979, Lt. Col. William Whitaker proposed "Ada" — both to honor Lovelace and to provide a name that was short, memorable, and unencumbered by existing trademarks. The choice was approved after contact with Lovelace's descendants. The MIL-STD number 1815 — her birth year — completed the tribute.

---

The deepest way to understand Ada is to contrast it with [[C_Programming_Language|C]] — the language Ada was explicitly designed to be safer than:

| Dimension | C | Ada |

|---|---|---|

| Philosophy | Trust the programmer | Protect the programmer from mistakes |

| Type system | Weak, implicit conversions everywhere | Strong, no implicit conversions |

| Array bounds | Not checked (buffer overflows) | Checked at runtime (CONSTRAINT_ERROR) |

| Integer overflow | Undefined behavior (signed) | Raises CONSTRAINT_ERROR |

| Null pointers | Allowed, often crashes silently | Access types with null checks; SPARK eliminates them |

| Concurrency | Library-only (pthreads) | Language-level tasks, protected objects, rendezvous |

| Module system | `#include` (textual paste) | Packages (semantic, enforced) |

| Generics | None (macros or `void*`) | Full generic packages and subprograms |

| Readability | Write-optimized | Read-optimized |

| Compilation | Fast | Slower (more checking) |

| Ecosystem | Enormous | Small but specialized |

The trade-off is clear: C optimizes for the programmer's freedom and the machine's speed. Ada optimizes for the program's correctness and the maintainer's sanity. In domains where bugs kill people — avionics, defense, medical, railway — Ada's trade-off wins. In domains where development speed and ecosystem breadth matter most — web services, mobile apps, scripting — C's descendants win.

Neither trade-off is universally correct. The choice depends on what failure costs.

---

Ada is not perfect. Its critics have always had legitimate grievances:

**Verbosity.** Ada code is longer than equivalent C, C++, or Python code. The language's designers argued that readability is more important than writability — that code is read far more often than it is written, especially in long-lived systems. But the verbosity makes Ada harder to learn, slower to prototype, and less attractive for projects where development speed matters more than long-term maintenance.

**Ecosystem size.** Ada's library ecosystem is tiny compared to C, C++, Python, JavaScript, or Rust. The Alire package manager has hundreds of crates; crates.io has over 170,000. For many practical development tasks — web servers, database access, GUI frameworks, machine learning — the library simply does not exist in Ada, or exists in a less mature form.

**Learning curve and talent pool.** Few universities teach Ada. The talent pool is small and aging. Companies that choose Ada face higher hiring costs and longer ramp-up times. This is a self-reinforcing cycle: fewer developers means fewer libraries means fewer new projects means fewer developers.

**Compiler cost and availability.** Historically, Ada compilers were expensive. GNAT has largely solved this, but the perception persists. And GNAT's compile times are slower than C or Go (though faster than C++ templates or Rust's monomorphization).

**The mandate's legacy.** Many engineers who were forced to use Ada in the 1980s and 1990s associate it with bureaucratic overhead, government inefficiency, and imposed technology choices. This emotional residue is real and has damaged Ada's reputation beyond what the language itself deserves.

These are genuine weaknesses. They explain why Ada has not achieved broader adoption outside its safety-critical niche. But within that niche — avionics, defense, railway, nuclear, air traffic control — Ada remains the language of choice because its strengths align precisely with the domain's requirements.

**The counter-argument from Ada practitioners**: the "small ecosystem" complaint is less relevant than it sounds. Ada projects do not need a web framework or a machine learning library — they need a real-time scheduler, a formal verification tool, and a compiler that generates deterministic code for a Motorola 68040 or a LEON SPARC processor on a satellite. In those domains, Ada's ecosystem is complete. The complaint about ecosystem size is often a comparison against the wrong benchmark — comparing Ada's library count to Python's is like comparing a surgical instrument catalog to a department store inventory.

---

The Ada ecosystem has modernized significantly in recent years. **Alire** (Ada Library Repository) is Ada's answer to Cargo, pip, or npm — a package manager and build tool that manages dependencies, builds projects, and provides a growing registry of reusable libraries (called "crates," borrowing Rust's terminology).

Alire was first released in 2019 and has grown steadily. By 2026, the Alire registry includes hundreds of crates covering:

- Cryptography and TLS

- JSON, XML, YAML, and TOML parsing

- HTTP clients and servers

- GUI frameworks (GTKAda, SDL bindings)

- Database interfaces (SQLite, PostgreSQL)

- Scientific computing and linear algebra

- Embedded systems HALs (ARM, RISC-V)

- Testing frameworks

- Logging and configuration

A modern Ada project can be started with:

```

alr init my_project

alr with aws    -- Add Ada Web Server dependency

alr build       -- Build everything

```

This is not yet as seamless as `cargo new` or `go mod init`, but it represents a fundamental shift from the era when starting an Ada project required purchasing a commercial IDE and manually configuring project files. The barrier to entry has never been lower.

---

Ada's concurrency model — tasks, protected objects, rendezvous — is powerful but general. For hard real-time systems where determinism is a life-or-death requirement, the full Ada tasking model offers too many options: dynamic task creation, arbitrary entry queuing, complex select statements. These features make timing analysis difficult or impossible.

The **Ravenscar profile**, named after Ravenscar, Yorkshire, where it was defined at the 8th International Real-Time Ada Workshop in 1997, restricts Ada's tasking model to a safe, analyzable subset. Under Ravenscar:

- All tasks are created at startup (no dynamic task creation)

- Each protected entry has at most one caller queued

- No abort statements

- No requeue

- No select statements

- No relative delays

- FIFO-within-priorities scheduling

- Ceiling locking protocol

These restrictions make the system's timing behavior **statically analyzable**. A schedulability analyzer can examine all the tasks, their priorities, their worst-case execution times, and their resource usage, and prove mathematically that all deadlines will be met. This is a requirement for DO-178C Level A (catastrophic failure condition) certification in civil aviation and equivalent military standards.

Ada 2022 added the **Jorvik profile** (named after the Viking name for York, UK, near Ravenscar) — a slightly relaxed version that allows more flexibility while retaining enough restrictions for scheduling analysis. Jorvik permits multiple entry callers and more flexible barriers, broadening the range of systems that can be formally analyzed.

The Ravenscar profile transforms Ada from a general-purpose language into a certifiable real-time language. A program written under Ravenscar constraints can be subjected to Rate Monotonic Analysis (RMA) or response-time analysis, and the results are mathematically guaranteed — assuming correct worst-case execution time estimates. This is not testing (which can only show the presence of bugs); it is proof (which demonstrates the absence of timing violations for all possible execution traces).

No other mainstream programming language has standardized real-time profiles at the language level. C and C++ rely entirely on operating-system-specific APIs (POSIX real-time extensions, VxWorks, RTEMS). Rust's Embassy framework provides async for embedded systems but does not offer the kind of formal schedulability analysis that Ravenscar enables. Ada's integration of real-time constraints into the language standard is unique.

---

Ada's safety-critical dominance is reinforced by its alignment with international certification standards:

**DO-178C** (civil aviation, FAA/EASA) — the standard for airborne software. DO-178C defines five levels (A through E) based on failure severity. Level A (catastrophic — loss of aircraft) requires MC/DC coverage, formal methods, and rigorous verification. Ada's strong typing, runtime checks, and SPARK's formal verification map directly to DO-178C objectives. The standard does not mandate Ada, but Ada (and SPARK) satisfy its requirements more naturally than C or C++.

**ISO 26262** (automotive safety) — the standard for automotive functional safety. MISRA C is more common in automotive, but Ada is used in some high-assurance automotive applications, particularly where formal verification is required.

**EN 50128** (railway) — the European standard for railway software safety. Ada and SPARK are widely used for SIL 3 and SIL 4 railway applications. The Paris Métro Line 14 (SIL 4) is the most famous example.

**IEC 62304** (medical devices) — the standard for medical device software lifecycle. Ada's safety properties are relevant here, though C remains more common due to embedded hardware constraints.

**Common Criteria** (security evaluation, ISO 15408) — Ada and SPARK have been used in systems certified to the highest Common Criteria evaluation levels. MULTOS, the smart card operating system, achieved ITSEC E6 (equivalent to EAL7) — the highest commercial security evaluation ever — with SPARK.

The pattern across all these standards is consistent: the more rigorous the safety or security requirement, the stronger Ada's advantage. This is not coincidental — it is the direct result of the design decisions the HOLWG made in 1975–1978, when they weighted reliability and maintainability above all other criteria.

---

Ada's contributions to programming language design extend far beyond its own user community. Many features that modern programmers take for granted were pioneered or popularized by Ada:

| Feature | Ada (year) | Later adoption |

|---|---|---|

| Packages / modules | 1983 | Java packages (1995), C# namespaces (2000), Rust modules (2015) |

| Generic programming | 1983 | C++ templates (1990), Java generics (2004), Go generics (2022) |

| Exception handling | 1983 | C++ exceptions (1990), Java (1995), Python, C#, Rust's `Result` |

| Strong typing with named types | 1983 | Haskell newtypes (1990), Rust newtype pattern, TypeScript branded types |

| Contract-based programming | 2012 | Eiffel (1986, mutual influence), Rust contracts (RFC stage), C++ contracts (proposed) |

| Range-constrained subtypes | 1983 | Pascal (earlier, less powerful), Rust range types (discussion) |

| Task-based concurrency | 1983 | Erlang processes (1986), Go goroutines (2009), structured concurrency (2018+) |

| Compiler validation suites | 1983 | GCC test suite, LLVM LIT, TC39 Test262 |

| Protected objects | 1995 | Java synchronized (1995), Rust `Mutex<T>` (2015) |

The influence is not always direct — languages borrow from each other in complex, overlapping ways — but Ada's contribution to the vocabulary of safe, concurrent, modular programming is undeniable.

**VHDL** deserves special mention: the hardware description language used to design integrated circuits is syntactically and semantically derived from Ada. VHDL's designers deliberately chose Ada's syntax so that hardware engineers and software engineers could read each other's work. Every modern chip — every CPU, GPU, FPGA, and ASIC — was at least partly designed using a language whose syntax came from Ada.

---

Beyond Ichbiah, several figures were critical to Ada's success:

**Col. William Whitaker** — the Air Force officer who led the HOLWG through its formative stages. Whitaker was not a language designer; he was a program manager with the vision to see that the software crisis required a language-level solution and the bureaucratic skill to navigate DoD politics. He proposed naming the language "Ada" and chose the MIL-STD number 1815. Without Whitaker, the HOLWG would likely have produced a requirements document and nothing more.

**David A. Fisher** — responsible for the development and iteration of the requirements documents, from Strawman through Steelman. Fisher's methodical approach — soliciting international review at each stage, insisting on feasibility analysis, and refusing to finalize requirements prematurely — gave the Ada project its intellectual rigor.

**Tucker Taft** — of Intermetrics (later Rational, then AdaCore). Taft led the design of Ada 95, Ada 2005, Ada 2012, and Ada 2022 — effectively serving as Ada's chief architect for thirty years. He has been called "the Bjarne Stroustrup of Ada," but unlike Stroustrup, Taft has maintained remarkable consistency across four major language revisions while avoiding the complexity explosion that C++ experienced.

**Robert Dewar** (1945–2015) — co-founded AdaCore and led the development of GNAT. Dewar was a professor at New York University who recognized that Ada's survival depended on having a free, high-quality compiler available to everyone. GNAT, built on GCC and initially funded by a U.S. Air Force contract to NYU, democratized Ada in a way that the expensive commercial compilers never could. Dewar's insistence on GPL licensing for GNAT was controversial — commercial Ada vendors feared it would undermine their business — but it ensured that Ada would survive the end of the mandate. Without GNAT, Ada might have followed the path of other government-mandated technologies: used under duress, abandoned the moment the mandate lifted, and forgotten within a decade. GNAT prevented that outcome by making Ada free, which meant Ada could survive on technical merit rather than institutional force.

**Jean-Pierre Rosen** — a French Ada educator and consultant who has spent decades teaching Ada, writing about Ada, and advocating for Ada in the European industrial community. Rosen's work has been particularly influential in the French railway and aerospace sectors.

---

The [[ALB Ada backend]] is one of [[AdaLogic BASIC]]'s emitters: it compiles ALB programs to Ada source code, which can then be compiled by GNAT or any other Ada compiler. The choice of Ada as a backend target reflects the same philosophy as the [[ALB C backend|C backend]] — targeting a language with strong compiler support and guaranteed portability — but with Ada's additional guarantees of type safety and constraint checking.

The ALB project's own toolchain is built in Ada (using GNAT and `gprbuild`), reflecting the team's commitment to the safety and correctness principles that Ada embodies. This is a concrete example of Ada's role as both a compilation target and a development tool: ALB compiles *to* Ada, and ALB itself is compiled *from* Ada. The relationship is symbiotic, and it demonstrates Ada's viability as a practical engineering choice in 2026 — not just a historical curiosity or a government mandate from the Cold War.

---

| Year | Event |

|---|---|

| 1815 | Augusta Ada Byron (later Lovelace) born, December 10 |

| 1843 | Ada Lovelace publishes Note G — the first computer program |

| 1968 | NATO Software Engineering Conference identifies the "software crisis" |

| 1974 | DoD studies reveal 450+ languages in use; software costs exceed $3B/year |

| 1975 | HOLWG chartered; Strawman requirements published |

| 1976 | Tinman requirements |

| 1977 | Ironman requirements; four contractor teams funded (Red, Blue, Green, Yellow) |

| 1978 | Steelman requirements finalized; Yellow and Blue eliminated; Red and Green advance |

| 1979 | Green selected; language named "Ada" |

| 1980 | MIL-STD-1815 published (December) |

| 1983 | MIL-STD-1815A / ANSI standard published (February); first validated compilers |

| 1987 | DoD Directive 3405.1 mandates Ada for all defense software |

| 1990 | Congressional Ada mandate enacted (Public Law 101-511) |

| 1995 | Ada 95 (ISO 8652:1995) — first ISO-standardized OOP language |

| 1996 | Ariane 5 Flight 501 failure (Ada software, requirements/testing error) |

| 1997 | Ada mandate relaxed by ASD(C3I) memorandum |

| 1998 | DoD Directive 3405.1 canceled; Ada mandate formally ends |

| 2005 | Ada 2005 (ISO 8652:2005) — interfaces, improved containers |

| 2012 | Ada 2012 (ISO 8652:2012) — contract-based programming |

| 2019 | Alire package manager first released |

| 2021 | AdaCore Community Edition; GNAT freely available |

| 2022 | NSA recommends Ada as a memory-safe language |

| 2023 | Ada 2022 (ISO 8652:2023) published May — parallel constructs, Jorvik profile |

| 2024 | White House ONCD recommends memory-safe languages including Ada |

| 2025 | ISO 8652 marked "to be revised" — next Ada edition in progress |

| 2026 | AdaCore reports significant increase in aerospace/defense design wins |

---

- [ ] Who designed the Ada programming language, and for which organization?

- [ ] What was the name of the final requirements document that the winning Ada design had to satisfy?

- [ ] Why was the military standard numbered MIL-STD-1815?

- [ ] What U.S. law required the DoD to write software in Ada, and when was it enacted?

- [ ] What percentage of the Boeing 777's avionics software is written in Ada?

- [ ] What caused the Ariane 5 failure in 1996 — was it an Ada bug, a requirements bug, or a testing bug?

- [ ] What is SPARK, and what can it prove about a program?

- [ ] What driverless railway system runs on formally verified SPARK code?

- [ ] Name three combat aircraft whose mission software is written in Ada.

- [ ] What government agency recommended Ada as a "memory-safe language" in 2022?

```hide Show answers

1 — **Jean Ichbiah** of **CII Honeywell Bull** (Paris), for the **U.S. Department of Defense** · 2 — the **Steelman** requirements document (June 1978) · 3 — **1815 is the year Ada Lovelace was born** (December 10, 1815) · 4 — **Section 8084 of the FY 1991 Defense Appropriations Act** (Public Law 101-511), signed November 5, 1990; refined as Section 9070 in the FY 1993 act · 5 — **99.9%** · 6 — a **requirements and testing failure** — the software correctly raised Ada's `CONSTRAINT_ERROR` on a 64-to-16-bit integer overflow, but no exception handler was present, and the Ariane 4 code was reused on Ariane 5 without re-verification · 7 — **SPARK** is a formally verifiable subset of Ada; GNATprove can prove **absence of runtime errors**, **data flow correctness**, **information flow correctness**, and **functional correctness** (that code satisfies its contracts) · 8 — **Paris Métro Line 14** (RATP, certified SIL 4, operational since 1998) · 9 — any three of: **F-15 Eagle**, **F-16 Fighting Falcon**, **F/A-18 Hornet**, **F-22 Raptor**, **Eurofighter Typhoon**, **JAS 39 Gripen**, **Dassault Rafale**, **AH-64 Apache** · 10 — the **U.S. National Security Agency** (NSA), in a November 2022 cybersecurity information sheet.

```

---

- [[SPARK_Ada|SPARK]] — the formally verifiable subset of Ada; Ada's most powerful capability

- [[Ada Lovelace]] — the language's namesake

- [[ALB Ada backend]] — AdaLogic BASIC's Ada emitter

- [[Rust_(programming_language)|Rust]] — the modern memory-safe systems language

- [[C_Programming_Language|C]] — the language Ada was designed to be safer than

- [[FORTRAN]] · [[COBOL]] · [[ALGOL]] — Ada's contemporaries

- [[History of Programming]]

- [[AdaLogic BASIC]]

[1] D. A. Fisher, "DoD's Common Programming Language Effort," *Computer*, March 1978. HOLWG, "The Department of Defense Common High Order Language Program," 1975–1980.

[2] J. D. Ichbiah et al., "Reference Manual for the Ada Programming Language: Proposed Standard Document," DARPA/IPTO, July 1980 (DTIC ADA090709). Available at apps.dtic.mil.

[3] "Ada—the project: the DoD high order language working group," ACM SIGPLAN Notices, Vol. 28, No. 3, March 1993.

[4] U.S. Congress, Section 9070, FY 1993 Department of Defense Appropriations Act (Public Law 102-396), October 6, 1992. Text at archive.adaic.com/pol-hist/policy/mandate.txt.

[5] AdaCore, "AdaCore Reports Increased Adoption of Memory-Safe Programming Languages," July 2026; VDC Strategy, "Memory-Safe Languages Offer Protection for Devices and TCO," 2026.

[6] "The Boeing 777 Flies on 99.9% Ada," archive.adaic.com/projects/atwork/boeing.html.

[7] Ariane 501 Inquiry Board, "Ariane 5: Flight 501 Failure," Report by the Inquiry Board, July 1996.

[8] ISO/IEC 8652:2023, "Information technology — Programming languages — Ada," published May 2023.

[9] AdaCore, "Developing Military Grade Software," adacore.com/uploads/papers/.

[10] DoD Directive 3405.1, "Computer Programming Language Policy," April 2, 1987. Canceled April 29, 1997.

[[Category:Languages]]

[[Category:Programming]]