> 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!).
That's for sure!
> 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.
You should certainly avoid poor management, poor process, and a
poor design ;-).
On the other hand, for a given organization, with a given process, and a
given set of people, the empirical evidence is that the choice of tools can
make a big difference. Furthermore, as time goes on, it is the source code of
a system that persists, long after the design process has finished,
and the original developers have moved on. It is the strong consistency
checking features of the programming language that protect the structural
integrity of the system from the slings and arrows of maintenance programmers.
> Ada should be part of an overall strategy to develop reliable, predictable,
> safe software.
The interesting thing about Ada, is that experience shows
that adopting it seems to help improve the programming culture,
as it helps people focus on specifications and abstractions, rather
than just code.
My experience with Java is not as good, largely because classes
combine spec and body; Java's interface types help, but you can't
put constructors or static methods in interfaces, so you still end up
having to look at a mish-mosh of spec and body information, which is
a royal pain to wade through.
> Bill Taylor
> [log in to unmask]