Previous Table of Contents Next


Part V
Ada 95

10  Ada 95 in Context

Chapter 10
Ada 95 in Context

by Michael B. Feldman

10.1. Introduction

Ada is alive and well and might well be found in your trains, planes, and automobiles, not to mention satellites, steel mills, and—if you live in Switzerland—your bank.

This chapter introduces you to the Ada programming language. The chapter is organized as follows:

  Section 10.2, “Preliminaries”: Ada history, the Ada 95 project, and Ada compiler validation
  Section 10.3, “Ada in Today’s World”: Defense and non-defense projects, Ada in education, Ada compiler availability
  Section 10.4, “Programming in Ada”: A tour of the language via annotated complete, compilable, tested examples
  Section 10.5, “Bibliography”: A list of useful sources for further information

The current Ada standard is Ada 95; the language of the original Ada standard is now referred to as Ada 83. Throughout this chapter, when I refer to Ada I mean Ada 95, except in the historical section. Where necessary to full understanding, I distinguish between Ada 83 and Ada 95, but I keep this distinction to a minimum.

Frequently, I refer to the wealth of materials available on the World Wide Web. With the exception of published books, nearly every conceivable Ada document is available on the Web, as are freely downloadable compilers. These resources are collected at five main Web sites, whose uniform resource locators (URLs, or addresses) are given in section 10.5. The sites are

  Ada Programming Language Resources for Educators and Students, sponsored by the Education Working Group of the ACM Special Interest Group on Ada (SIGAda), which I maintain and refer to here as the “Educator site”
  Ada Information Clearinghouse (Ada IC), operated by IIT Research Institute under contract to the Ada Joint Program Office (AJPO) in the U.S. Government and referred to as the “Ada IC site”
  Public Ada Library (PAL), a very large collection of Ada documents, programs, compilers, and so on, maintained by Richard Conn on the Washington University (St. Louis) Internet archive server and referred to as “the PAL”
  Home of the Brave Ada Programmers, maintained in Switzerland by Magnus Kempe and referred to as “HBAP”
  ACM Special Interest Group on Ada, referred to as “SIGAda”

In referring to specific files and other resources on the Web, I have refrained from giving detailed URLs, as these have an annoying tendency to change. All the sites are organized for quick search and retrieval and contain many references to resources on the other sites, so I deem it better just to mention the overall site name and leave it the reader to pay an electronic visit.

10.2. Preliminaries

This section briefly reviews the history of Ada 83 and Ada 95 and discusses the important process of validation of Ada implementations.

10.2.1. A Brief Historical Sketch of Ada 83

This chapter is not intended as a historical document, but one can best assess a technical contribution if one acquires some understanding of the history and context of that contribution. This section therefore provides a historical sketch of Ada.

10.2.1.1. The Early History of Ada 83

The history of Ada 83 has been written exhaustively—and entertainingly—in a paper in the Second History of Programming Languages Conference (HOPL-II) by William Whitaker (Whitaker, 1996). Whitaker led the original High Order Language Working Group (HOLWG) effort at the U.S. Department of Defense (DoD). This group wrote the requirements for, and oversaw the competition for the design of, the language that became Ada. Whitaker’s article also makes fascinating reading for its insights into the workings of a large organization. For this early history, excerpts from Whitaker’s account serve much more effectively than could my attempt to reword it.

To begin, I quote from Whitaker’s (1996) commentary on the reasons for desiring a common DoD language:

The proposal for language commonality across DoD was extremely radical at the time and initially met almost universal opposition. In fact, it was regarded as unrealistic to expect to use a high order language for embedded systems. It may be surprising that a consensus did not mandate a common high order language for embedded systems much earlier. There are, however, a number of managerial and technical constraints that acted against this. For many DoD systems, severe timing and memory considerations were dominant, governed by real-time interaction with the exterior environment.

Because of these constraints, and restrictions in developmental cost and time scale, many systems opted for assembly language programming. This decision was influenced by past experience with poor quality compilers and the fact that an assembler routinely comes with the machine, while the compiler and its tools usually must be developed after the project has begun. The advantages of high order languages, however, were compelling, and more systems turned to them. Because of limitations of available high order languages, the programs generated often included very large portions done in assembly code and linked to an HOL structure, negating many of the HOL advantages.

Further, many systems found it convenient to produce their own high order language or some incompatible dialect of an existing one. Since there was no general facility for control of existing languages, each systems office did the configuration control on its language and compilers and continued this for their particular dialect through the entire maintenance phase of the system. This had the effect of reducing the contractual flexibility of the Government and restricting competition in maintenance and further development.

This lack of commonality negated many advantages of high order languages including transportability, sharing of tools, the development of very powerful tools of high efficiency and, in fact, not only raised the total cost of existing tools, but in some cases essentially priced them out of the market. Development projects were very poorly supported and forced to live with technology far below what should be the state-of-the-art.

The target for a major language project was to be DoD “software in the large.” This is often given a limited interpretation, namely that DoD programs are individually large, which is certainly true and drives many of the technical requirements on the language. But the fact that the DoD has hundreds of such large programs provides an opportunity for economies of scale that are potentially much greater than the sum of individual projects. The problem is not just that of producing a subsystem of 200,000 lines of code, but of the servicing of a “system” that is all the code produced by the DoD for (by 1990) $30 billion per year (“programming in the very large”). This path drives other requirements and properties, like machine independence which forces the validation requirement and the rejection of subsets. But these advantages can be realized only if the technology is applied with consistency over the whole of the DoD, and an even larger community if possible. So a strong position from the DoD was vital to the plan.


Previous Table of Contents Next