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.