I have to admit that I share Bill's reservations about this claim. In my career I've dealt with some systems coded in 100% Ada that were so awful the only recourse was to recode them, in effect blowing the schedule and budget even worse. However, that was the only way to remedy the problem. The cause of this was certainly not Ada, but were all programmatic issues of unrealistic schedule, micromanagement, and requirements that changed more frequently than ABC's summer rerun schedule :-) And unfortunately Ada got caught up in "guilt by association". Very few observed that when "another **** Ada exception crashed the system", this was actually a good thing, because range violations and null pointer checks could've easily gone unnoticed if coded in other programming languages. However, that was faint praise for Ada in the context of that project. Bill Taylor wrote: > > > > > > > When you need software On Time and Under Budget > > Choose Ada > > > > > > There is a danger that such a claim will undermine the credibility of the > other (stronger) claims for Ada. > It appears far too naive. > > Using Ada is no guarantee of delivering on time and under budget, just as > using another language is no guarantee of failure to deliver on time and > within budget (but it certainly helps!). > > Choosing an appropriate process is far more significant in this respect than > choice of language. > Poor management, poor process, poor design will never bring a project in on > time and under budget, whatever language is chosen. > > Ada should be part of an overall strategy to develop reliable, predictable, > safe software. > > Bill Taylor > [log in to unmask] -- Marc A. Criley Chief Software Architect Lockheed Martin M&DS [log in to unmask] Phone: (610) 354-7861 Fax : (610) 354-7308 Speaking for myself, not my employer.