CORRECTNESS CORNERSTONE


  • Reference Manual for the Ada Programming Language, ANSI/MIL-STD-1815A-1983

  • - “Ada was designed with three overriding concerns: program reliability and maintenance, programming as a human activity, and efficiency.”
    - “. . . emphasis was placed on program readability over ease of writing.”
    - “. . . error-prone notations have been avoided.”
    - “. . . compilers can ensure that operations on variables are compatible with the properties intended for objects of the type.”

  • Bjarne Stroustrup, inventor of C++

  • - “C makes it easy to shoot yourself in the foot. C++ makes that harder but when you do, it blows away your whole leg.”

  • James Gosling - Inventor of Java

  • - Some languages, such as Ada, “fit well and are pretty straightforward” ports of the Java virutal machine. Sun will not attempt to run C and C++ code on the virtual machine, however, because it is more difficult to ensure the reliability and, therefore, the security of downloaded code.


Previous slide Contents END


From the Script: SLIDE 73 - Correctness Cornerstone

On this slide, additional information is provided that helps to conclude that Ada is the right choice where the six cornerstones listed on the last slide are important.

Many of these quotes are from C/C++ folks who admit that their technology does not scale up to meet these cornerstones. Others are from Ada's goals (shared by Ada 95) that clearly emphasize the goal of "getting it right" and "making it work".

The following are Ada's design goals as listed in the Ada 95 RM:

Ada was originally designed with three overriding concerns: program reliability and maintenance, programming as a human activity, and efficiency. This revision to the language was designed to provide greater flexibility and extensibility, additional control over storage management and synchronization, and standardized packages oriented toward supporting important application areas, while at the same time retaining the original emphasis on reliability, maintainability, 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 to a relatively small number of underlying concepts integrated in a consistent and systematic way while continuing to avoid the pitfalls of excessive involution. The design especially aims to provide language constructs that correspond intuitively to the normal expectations of users.

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 continues to be a central idea in the 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. An allied concern is the maintenance of programs to match changing requirements; type extension and the hierarchical library enable a program to be modified while minimizing disturbance to existing tested and trusted components.

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.