Re: ADA Popularity Discussion Request

[kevin.cline@gmail.com (Kevin Cline)]

"Richard  Riehle" <adaworks@earthlink.net> wrote in message news:<vS8%c.69$xA1.4@newsread3.news.pas.earthlink.net>...
> "Kevin Cline" <kevin.cline@gmail.com> wrote in message
> news:e749549b.0409051449.574ec9ce@posting.google.com...
> > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message
> news:<vpblkhspuA9F@eisner.encompasserve.org>...
> 
> > > But assuming perfect testing, finding the errors during compilation
> > > rather than in testing saves me time, and time is money.
> >
> > I thought so too, until I tried incremental test-first development.
> > Retesting a unit after adding a few lines of code means that type
> > mismatches are caught immediately with or without strong typing.  But
> > it goes faster if you don't have to compile and link every iteration.
> >
> This assumes that we are concerned only with type mismatches.   In
> Ada, we expect the compiler to provide a great deal more than that.
> 
> For small software systems, frequent testing can often be sufficient. As
> the size of the software increases, and complexity of that software grows,
> we must engage all the tools available and use them appropriately to
> ensure the correctness of our design.   Also, in large software systems,
> it is not possible to test every path, every possible value of a variable,
> and every potential timing problem.
> 
> How does one test for a race condition?   

I don't test for race conditions.  I try to isolate code potentially
subject to race conditions or deadlocks to a small program unit, and
then, if necessary, prove it correct.

> Does that test guarantee
> no race condition can occur?  

> This is not a type checking issue, but
> it is a design issue where the type model can be one of many factors
> in reasoning about the stability of the design.
> 
> How does one test for a runaway pointer or dangling reference?  

I don't test for these.  As a general rule, I don't write code that
would make them possible.  When I do have to write unsafe code, then I
encapsulate it tightly so that the code is either obviously correct or
can be verified correct in short order.

> Again,
> this is not strictly a type issue, except that Ada's overall set of rules,
> including the type rules, provide some tools for reasoning about this
> intelligently.

Working safely with dynamically allocated objects in Ada-83 means
using unhecked_allocation and deallocation, which reqired almost as
much diligence
as using malloc/free in C.  Then C++ appeared with constructors and
destructors and auto_ptr, and memory management got a lot easier. 
Then Ada-95 added controlled types, but by then C++ had huge
mindshare.

> Finally, testing can only test for what we know needs to be tested.   We
> must design for the unexpected, even as we test for the expected.  It is
> impossible to test for the unexpected.   The Ada type model includes
> both the compile-time checking and the run-time checking.   The rest
> of Ada provides a wide range of compile-time checks.
> 
> Those who fail to understand this should stay away from building software
> that requires a high degree of dependability.

What do you mean by the unexpected?  It seems that everything that
could happen to software can be anticipated, except for total failure
of the underlying execution engine.  Or do you mean unexpected
exceptions or incorrect values returned by unexpected software errors?