What are the main differences between the original Ada and the 95 revision?

The "big three" Ada 95 language revisions were Hierarchical Libraries, Protected Objects, and Object-Oriented Programming. Hierarchical Libraries referred to the enhancement of the Ada module namespace to take it from Ada 83's simple "flat" namespace of "library units," where each unit had a single unique identifier, to a hierarchical namespace of units, with visibility control between parent and child library unit.

Protected Objects referred to the new "passive," data-oriented synchronization construct that we defined to augment the existing "active" message/rendezvous-oriented "task" construct of Ada 83.

Object-Oriented Programming was provided in Ada 95 by enhancing an existing "derived type" capability of Ada 83, by supporting type extension as part of deriving from an existing type, as well as supporting run-time polymorphism with the equivalent of "virtual functions" and run-time type "tags."

What prompted the Ada revision in 95?

ISO standards go through regular revision cycles. Generally every five years a standard must be reviewed, and at least every ten years it must be revised. There were also some specific concerns about the language, though generally the language had turned out to be a reasonably good fit to the needs of mission-critical software development.

In particular, Ada's strong support for abstract data types in the guise of packages and private types had emerged as a significant step up in software engineering, and Ada's run-time checking for array bounds and null pointers had helped catch a large class of typical programming errors earlier in the life-cycle.

Was there a particular problem you were trying to solve?

Object-oriented programming was growing in popularity at the time, though it was still not fully trusted by much of the mission-critical software development community. In addition, the Ada 83 tasking model was considered elegant, but did not provide the level of efficiency or control that many real-time system developers would have preferred.

Once the Ada 9X revision process began, a "requirements" team was formed to solicit explicit comments from the Ada community about the language, both in terms of things to preserve and things to improve.

Have you faced any hard decisions in your revision of Ada?

Every language-design decision was pretty hard, because there were many goals and requirements, some of which were potentially conflicting. Perhaps the most difficult decisions were political ones, where I realized that to achieve consensus in the language revision process among the ISO delegations, we (the design team) would have to give up some of our personal "favourite" revision proposals.

Are you still working with the language now and in what context?

Yes, I am still working with the language, both as a user and as a language designer. As you may know the newest version of the language, known as Ada 2005, just recently achieved official standardization. The Ada 2005 design process was quite different from the Ada 95 process, because Ada 2005 had no Department of Defense supported design team, and instead had to rely on strictly voluntary contributions of time and energy.

Nevertheless, I am extremely proud of the accomplishments of the Ada 2005 design working group. We managed to "round out" many of the capabilities of Ada 95 into a language that overall I believe is even better integrated, is more powerful and flexible, while also being even safer and more secure.

Would you have done anything differently in the development of Ada 95 or Ada 2005 if you had the chance?

The few technical problems in the development of Ada 95 that emerged later during use were either remedied immediately, if minor, through the normal language maintenance activities ("we couldn't have meant *that*... we clearly meant to say *this*"). Or if more major, were largely addressed in the Ada 2005 process. From a process point of view, however, I underestimated the effort required in building international consensus, and in retrospect I should have spent more time establishing the rationale for revision proposals before "springing" them on the panel of "distinguished reviewers" and the ISO delegations.