• Weak Object-Oriented Support
• Lack of Bindings
• Real-Time Support
• Size of Compilers/Real-Time
• Not Current with Technology

From the Script: SLIDE 20 - What Was Wrong With Ada 83?

When the standard was introduced, there was nothing wrong with Ada. In fact, some would argue that Ada was ahead of its time. However, as with any language, there must be a logical evolution in order to maintain pace with user requirements.

We know far more about OOT now than we did when Ada was first standardized. The object-oriented support built into Ada 83, called “object-based” by some, was based on the OO concepts available during the late seventies and early eighties.

Ada 83 was, and continues to be, caught in a catch-22. Commercial vendors didn’t expend funds to develop tools and bindings for the language because there didn’t appear to be a large and profitable marketplace in which to sell them. Marketplace users didn’t develop applications using the language because the tools and bindings available were expensive and few in number. Smaller companies didn’t use the language because of the initial start-up costs. Larger companies didn’t use the language because the marketplace appeared to be limited, the profit and potential appeared to be small.

Compared to Ada language compilers, other language compilers (such as C++, Visual BASIC, Smalltalk, and PASCAL) came with large libraries of tools designed to help the programmer quickly get started. Although many are proprietary, many of today's compilers come with complete frameworks; some are considered de facto standards, which support quickly developing full-featured applications (MS C++ Foundation Classes, Smalltalk Visual Works, Delphi, etc.). These frameworks allow the programmer to easily take advantage of such things as ODBC, OLE, TCP/IP, SQL etc.. This allows the developer to focus on using the functionality and not on developing this functionality.

At the time of development, Ada was the only general-purpose computer language that provided any support for real-time applications. Many large real-time, safety and mission critical systems have been developed using Ada. One criticism, though, was that the scheduling rules were unsatisfactory -- especially with regard to the rendezvous. First-in-first-out queuing on entries and the arbitrary selection from several open alternatives in a select statement lead to conflict with the normal preemptive priority rules. For example, priority inversion occurred when a high priority task was on an entry queue behind a lower priority task.

The early compilers for Ada produced large executables. Some of this was caused by the way the compilers handled 'withing in' another package (by reference, or by deep copy). Those that used a deep copy created extremely large executables, which were difficult to fit into target platforms. However, some of the problems in this area, especially when dealing with MIS targeted at the PC environment, were due to poor design on the part of the developers. Several developers created packages that supported only atomic values (in other words, only one data element per package and limited use of complex records). This meant that very large quantities of packages had to be 'withed in' to accomplish the goals of the development. Each Ada package created added significant amounts of overhead to the executable. Over time, the development of optimizing compilers -- and the experience of Ada users -- diminished this issue.

Every standardized language must evolve to meet user requirements -- Ada is no exception. It became obvious that a new version of Ada was needed -- one that would provide solutions to the raised issues, but would retain Ada 83’s good features. Ada 95 was the answer.