1.3. Design Goals and Sources

Ada was designed with three overriding concerns: program reliability and maintenance, programming as a human activity, and efficiency.

The need for languages that promote reliability and simplify maintenance is well established. Hence emphasis was placed on program readability over ease of writing. For example, the rules of the language require that program variables be explicitly declared and that their type be specified. Since the type of a variable is invariant, compilers can ensure that operations on variables are compatible with the properties intended for objects of the type. Furthermore, error-prone notations have been avoided, and the syntax of the language avoids the use of encoded forms in favor of more English-like constructs. Finally, the language offers support for separate compilation of program units in a way that facilitates program development and maintenance, and which provides the same degree of checking between units as within a unit.

Concern for the human programmer was also stressed during the design. Above all, an attempt was made to keep the language as small as possible, given the ambitious nature of the application domain. We have attempted to cover this domain with a small number of underlying concepts integrated in a consistent and systematic way. Nevertheless we have tried to avoid the pitfalls of excessive involution, and in the constant search for simpler designs we have tried to provide language constructs that correspond intuitively to what the users will normally expect.

Like many other human activities, the development of programs is becoming ever more decentralized and distributed. Consequently, the ability to assemble a program from independently produced software components has been a central idea in this design. The concepts of packages, of private types, and of generic units are directly related to this idea, which has ramifications in many other aspects of the language.

No language can avoid the problem of efficiency. Languages that require over-elaborate compilers, or that lead to the inefficient use of storage or execution time, force these inefficiencies on all machines and on all programs. Every construct of the language was examined in the light of present implementation techniques. Any proposed construct whose implementation was unclear or that required excessive machine resources was rejected.

None of the above design goals was considered as achievable after the fact. The design goals drove the entire design process from the beginning.

A perpetual difficulty in language design is that one must both identify the capabilities required by the application domain and design language features that provide these capabilities. The difficulty existed in this design, although to a lesser degree than usual because of the Steelman requirements. These requirements often simplified the design process by allowing it to concentrate on the design of a given system providing a well defined set of capabilities, rather than on the definition of the capabilities themselves.

Another significant simplification of the design work resulted from earlier experience acquired by several successful Pascal derivatives developed with similar goals. These are the languages Euclid, Lis, Mesa, Modula, and Sue. Many of the key ideas and syntactic forms developed in these languages have counterparts in Ada. Several existing languages such as Algol 68 and Simula, and also recent research languages such as Alphard and Clu, influenced this language in several respects, although to a lesser degree than did the Pascal family.

Finally, the evaluation reports received on an earlier formulation (the Green language), and on alternative proposals (the Red, Blue, and Yellow languages), the language reviews that took place at different stages of this project, and the thousands of comments received from fifteen different countries during the preliminary stages of the Ada design and during the ANSI canvass, all had a significant impact on the standard definition of the language.