From: adaworks@... Date: 2008-04-19T15:10:10+09:00 Subject: Re: Ada vs Ruby "Mike Silva" wrote in message news:4db7bd18-0df0-401e-b75d-abf4b3342513@a22g2000hsc.googlegroups.com... On Apr 17, 12:16 am, "Arved Sandstrom" 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