"Mike Silva" <snarflemike / yahoo.com> wrote in message 
news:4db7bd18-0df0-401e-b75d-abf4b3342513 / a22g2000hsc.googlegroups.com...
On Apr 17, 12:16 am, "Arved Sandstrom" <asandst... / accesswave.ca>
wrote:
>
> ....Having said that, it seems to me that the better correctness of programs 
> in
> SPARK or Ada compared to C/C++, say, would also be due to the qualities of
> organizations that tend to use/adopt these languages.....

MS>>I think there's a lot to be said for this.  Organizations that choose
MS>>bad tools when better tools are available show that at some level they
MS>>are not properly serious, and/or not properly informed (which points
MS>>again to not being properly serious).

I have often wondered why someone would choose an error-prone language
such as C++ and expect an error-free result.   More recently, I have been 
looking
more closely at Java and have learned that it too is far more error-prone than
one might expect.

As to Ada.  Some have touted Ada's type-safety as an important feature of the
language.  This is certainly one important feature.   There are others that are 
not
as immediately obvious -- features not found in most other languages -- that
contribute to the better engineering model provided by Ada.   Although many
Ada programmers do not understand Chapter Eight of the Ada Language
Reference Manual, the visibility model of the language is, when understood
and used as part of a software design, a powerful part of what makes Ada
so robust for safety-critical software.    The architectural model of an Ada
program also lends itself to the design of well-formed, easy-to-read, and
scalable software.  That is, as programs become larger, as they tend to do
in real software, Ada tends to scale-up a little better than most other 
languages.

Ada is not the right language for small, toy programs, but it begins to show its
power for programs in the 100 KSLOC range or higher.   We have Ada software
in the million SLOC range and higher.  In those kinds of systems, Ada really
outshines most competing languages.    This is, in part, due to its 
architectural
constructs:  the package model, the separate compilation model, the child
library unit model, and the way both inheritance and genericity are designed
into the language.

Richard Riehle