A da is now entering its third standard incarnation, currently known as Ada 2005. Its earlier incarnations were Ada 83, which was designed in the late 1970s and early 1980s by a team led by Jean Ichbiah, and Ada 95, which was designed in the early 1990s by a team led by this author. In contrast to the earlier incarnations, Ada 2005 was designed by a largely volunteer committee, led by Pascal Leroy. The only member of the committee actually on the payroll was Randy Brukardt, who was supported by

more »

... AdaEurope and the Ada Resource Association in his official role as editor of the new standard. The lack of a full-time design team to drive and shape the design process created misgivings among some members of the committee who felt it could impede the process. The design-by-committee process has a well-deserved reputation for producing awkward and unpleasant collections of disjointed compromises. The question was whether the Ada 2005 process could sidestep these pitfalls. With a full-time design team and a clear team leader, the Ada 95 revision benefited from a cohesive vision that kept the design from becoming a scattered combination of ideas. With a volunteer committee, there was a danger that the need to create consensus without the hierarchy present in a design team would result in inconsistencies, that each committee member would be mollified by being given their own pet feature, and the language would descend into a balkanized conglomerate of sublanguages. Ada 2005 seems to have escaped the notorious design-by-committee problems. The proposed changes seem to have brought the language into a state where it is, if anything, more integrated and more consistent. How was this accomplished? In retrospect, the key factor in achieving this desired goal has been a strong, shared, language-design philosophy driving design decisions. This kind of shared philosophy might not have been possible in earlier Ada standardization activities, as the language and the community of users were still relatively new. For the Ada 2005 process, we had a set of committee members with many years of experience both as users and implementors of Ada and a shared vision of what makes Ada powerful and productive, namely its unique combination of safety, flexibility, efficiency, and its real-time support. Our goal in Ada 2005 was to preserve and enhance these strengths while reducing any impediments to productive use. The two anchors in the shared vision were safety and efficiency, with safety given more weight -though never absolute precedence -when there was a conflict. Ada's focus on safety is in strong contrast with certain other languages, where the attitude might be expressed as give programmers very sharp tools and then get out of their way, although this latter attitude sounds great for real programmers. In fact, even the best programmers make mistakes. Part of the Ada philosophy is that by appropriate human engineering, you can produce a language that is in the end more productive. The design of the language allows the compiler and the run-time to catch typical programmer errors before they become tedious debugging problems. To illustrate how this shared philosophy interacted with the Ada 2005 design process, it is useful to study the evolution of a particular Ada 2005 feature as it moved from a perceived language problem -through the debates over the multiple ways to solve it and finally to the ultimate consensus around one particular solution. One of the first challenges for the Ada 2005 revision was allowing for mutual dependence among types that were not all declared in the same package. As an example, one might have a type representing employees and another representing departments where a department record would include a pointer to the employee who is the manager, and the employee record would include a pointer to their department. In Ada 83 and Ada 95, by using an incomplete type declaration, a software engineer was able to define such mutually dependent types, but only if they were all in the same package. This limitation led to large, unwieldy packages, particularly in the context of object-oriented programming. Although this mutual dependence problem was one of the first identified, it was one of the last problems solved during the revision process. The problem proved extraordinarily difficult to solve in a way that satisfied the various criteria inherent in our shared design philosophy. In the end, seven different approaches were considered, six of which were considered viable: The Ada 2005 Language Design Process The Ada 2005 language design process was significantly different from that used by Ada 83 and Ada 95 in that it was based on an essentially volunteer committee rather than a full-time design team. Design-by-committee has a well-deserved reputation as being a sure way to create an awkward and unpleasant collection of disjointed compromises. Nevertheless, the result of the Ada 2005 process produced a language that is even better integrated and consistent than its predecessors. Producing this result depended on having a strong, shared, language design philosophy driving the design decisions. This article discusses this language design philosophy, contrasts it with the philosophy behind various other programming languages, and shows how the philosophy helped to ensure a successful, integrated, and consistent result.