Steve Rowell started out, titling his presentation as ADA, Just Say No. Ada is too much, too late. In the early eighties a compiler designer said "with in-depth knowledge of the target language and compiler construction a C compiler will take 3 man months, a Pascal compiler will take one man year and a ADA compiler will take 10 man years to write". This of course is heresy, yet consider the history that followed:

ADA compilers did take a long time to come up on new hardware. C compilers came up quick and were available day one, be it a new UNIX system or PC. The ADA compilers were many times more expensive. ADA basically missed the PC revolution, not becoming a popular language such as C or Pascal. ADA never gained grassroots support.

Now ADA is behind the times again. You just weren't cool in the 80's if you didn't use an object-oriented language. ADA was again, very late to the party. Though ADA finally gained recognition for supporting OOP, it failed to gain grassroots or wide-spread following as a language for OOP. Time to market for software solutions is often more critical than abundance of features. ADA has been slow getting to market. It is out of focus with critical industry needs. C/C++ and ADA are under some intense attacks due to growing concerns about security. For example, in a recent article in Fortune, Bill Joy described Windows as a kludged OS that was full of holes. One of the main reasons he cited was that C is a "dangerous language". I believe he meant this because C doesn't have a virtual machine as Java and C# do. Ada doesn't have a virtual machine either. A couple of weeks after this article Microsoft stock dropped 8% in one day due to news of OS holes. Type checking in low level routines is not considered as important as verification of the data from various locations before it is committed to application software (e.g. XML schemas). In fact, too much repetitive type checking is considered inefficient. Constraint checking in ADA is often turned off.

ADA has a steeper learning curve (at least it is perceived to be). Some argue that C++ is just as complex as ADA. This may or may not be true, but the learning curve for C++ is usually not done from scratch but incrementally from knowledge of a C or C-like language. Learning C++ is evolutionary, while learning ADA is viewed as revolutionary. The perception of Java, C, C++ and C# being relatives will by itself create an obstacle to investing in learning ADA. The pool of programmers already knowledgeable in C, C++, Java and/or C# is large and growing faster than the pool of ADA programmers.

There is a lack of industry support. Support by Commercial Off-The-Shelf (COTS) for ADA is at best an after thought. There is a lack of mature libraries and components (e.g. a windows framework). Tools are few and Lack competitive support. Special API's must often be provided. Currently I can't think of a hardware platform that doesn't have an existing C compiler (e.g. Palm, pocket PC's, smart phones, PIC's, etc.), this is not true for ADA. ADA lost its only influential friend. DOD no longer mandates ADA, but actively seeks COTS solutions.

COE (Common Operating Environment) is a military specification enforcing software requirements. The specification follows COTS very closely. For example, the part of COE that specifies the GUI for running under windows pretty much defaults to the Windows logo requirements. That is, if Microsoft will certify it then so will COE.

Click here to view Steve Rowell's slides

James Alstad 's presentation was titled ADA and Beyond, The View from 2003. This is an updating of the National Research Council's 1997 document "Ada and Beyond-Software Policies for the Department of Defense". Ada and Beyond emphasized life-cycle considerations. "Projects will specify and prioritize quality, cost, and schedule goals, and will analyze tradeoffs and the business case for particular decisions."

It defined a niche among DOD applications for Ada. " Warfighting software application"; "DOD will direct the maintenance of software"; "Software subsystem is large, more than 10,000 lines of code, or the subsystem is critical"; "There is no life-cycle cost-effectiveness justification for using another programming language".

It recommended considering choice of programming language within broader project review context. "The software engineering plan should cover: The systems scope and concept of operations; the key system and software requirements including stakeholder needs; the key elements of the system and software architecture, including programming language decision".

Zeigler published a study comparing Ada 83 and C in the development of the Verdix Ada Development System. The comparisons covered ten year's experience, over 1,000,000 SLOC in each language, and was balanced with respect to programmer experience, learning curve effects, and language productivity (SLOC per feature point).

Ada 83's cost per feature point was better than C's by a factor of 1.37. Ada 83's defects per feature point is better than C's by a factor of 5.9.

Alstad's conclusions:
Ada is far superior to C in density of delivered defects. Allowing that C++ is twice as good as C at catching defects then a C++ program will have about 3 times as many defects as a comparable Ada program. With other considerations (portability) Ada is intrinsically a better tool for developing software products.

Ada use is decreasing. What's a manager to do? Alstad recommends following "Ada and Beyond"'s recommendation to consider life-cycle costs and benefits: If one has a large base of existing software there is little point in rewriting software. If one has a base of existing programmers with focussed expertise, there would be a learning curve with a new language and development environment (on a new project), but this might be worthwhile on a large project, if the language has payoffs. Project characteristics versus language features can push the choice one way or another. Java is probably better than Ada for web software. Ada probably better than Java for an embedded system.

There are some non-issues. Some arguments raised against the use of Ada do not carry much weight. The argument that there's a lack of present and future ADA programmers. There are multiple teachers (in the LA area) whose business is teaching Ada. They have a record of success in getting Ada programmers started. Hire a computer science graduate who can pick up programming languages quickly and will become the local Ada expert.

The argument that there's a lack of tool support. There are multiple highly -featured supported tool environments available. There's one open source compiler (GNAT), so that an organization could, if necessary, maintain tools itself indefinitely as the source code is available. Stability of the ADA language means that environments don't need to change for that reason.

What is the future of Ada? Ada has a niche in engineering applications, in embedded systems and systems requiring high reliability. Alstad recommends that Ada advocates should worry Ada's success in its niche and not in the wider world. He recommends increased software engineering professionalism including explicit software engineering education, government standards for critical applications (Example: require a reliability level), and licensing of software professionals.

Ed Manderfield was introduced as shy and retiring and reluctant to speak. (For those of you who don't know him, this is the complete reverse of his personality). Ed says we need Six Sigma Programming on ultra-reliable computers to have highly reliable applications. Six Sigma came from hardware manufacturing systems and is badly needed in software. There are examples of former software systems that approached Six Sigma reliability, The Apollo Program, the Boeing Automated Landing System and heart monitor applications. Recent fads in computing are OOPSLA and SEIS and the Computer Maturity Model. Proponents of CMMI say "Six Sigma Programming" is impossible. Ed said it has already been done in a number of projects over the last 40 years.

His first example was the Apollo program. The Apollo program had not gone far when 3 astronauts died in a fire before the first scheduled test flight. Harrison Storms and Dutch Kindelberger requested doubling the budget to fix the problems and they got it. Ed described the thorough series of tests and flights of each of the test flights. The Lunar Guidance system was a highly reliable set of software produced by IBM. Apollo 10 went through most of the steps required for the Moon landing and Apollo 11 accomplishing it. There was a serious accident on Apollo 13 requiring abandoning the landing, but the LEM lifeboat returned the astronauts safely. Apollo 17 provided the last chance for man to walk on the Moon's surface during the 20th. century. Ed presented a sweeping and very interesting discussion of the Apollo program.

Other examples of highly reliable programming are Boeing's automatic landing system and heart monitors. Ed say's "Six Sigma Programming" would be impossible without ADA 95 because it is at present the only stable platform with advanced technology. Other languages can claim to be more object oriented, but lack stability and have severe defects in their design.

To get six sigma reliability results you need more than an advanced language. You need organization, Quality Assurance, Configuration Management, Testing, and Validation &Verification. A truly superior organization is required to get results. Periodic peer review of work in process is required.

Some implanted heart monitors have been working for 3 years and that is a system where you better have zero errors. If your life depends on it make sure you have six sigma programming and the programming is done in Ada 95.

This was an excellent presentation by the three speakers who expressed differing viewpoints. I do note that the differences were based more on perspective than differences on the technical aspects of the languages. Steve Rowell described problems of using Ada over a wide range of software development. Jim Alstad conceded that Ada would not be the right language for every use, but filled a very important niche. Ed Manderfield restricted his discussion to places where highly reliable software was needed and where failure would mean loss of life. You really had to be there to discern the differences in each speaker's approach.

This was the third meeting of the LA Chapter year and was attended by 18 persons.
Mike Walsh, LA ACM Secretary