Re: What is wrong with Ada?

[<adaworks@sbcglobal.net>]

"Pascal Obry" <pascal@obry.net> wrote in message 
news:461E6DD9.6010600@obry.net...
>
> "The only way" for interpreted languages, for compiled languages (as
> said in my previous message) the compiler will detect lot of mistakes.
> So it is not the only way in this case. I'm wondering if you are not
> moving to the troll side!
>
Every program needs to be evaluated in more than one way.  Those
who advocate test-only are off the mark.  Those who depend on a
properly compiled program are way off the mark.   Those who rely
on inspection alone, are certainly missing something.

Ideally, we design the software with the most appropriate methods and
tools to avoid defects.   For most circumstances, but not all, Ada is a
better tool to accomplish this than most other languages.   We can
certainly get better results in this regard from Ada than from an intepreted
language, but that is the old "mixing apples and oranges" issue.   When
comparing Ada, we must compare it to languages that are also compiled.
C++, a language inherently error-prone, is not usually as good as Ada
(with a few very rare exceptions), so we don't expect to be able to
depend on the compiler for as much help as we get from Ada.   This is
also true, to some extent, for Java.

Even so, with all the help we get from the compiler in a well-designed Ada
program, we must also apply some testing regimen and are well-advised to
add an inspection process.    However, it is well-known that neither testing
nor inspection are sufficient for evaluating the correctness of a program.  This
is why compiler errors are still important.   Once again, Ada excels in this
regard for most kinds of design problems.

Some of the examples given, so far, such as the double underbar indicate
a lack of understanding of just what a harsh mistress really is.  The 
fundamental
design goal of Ada is for a language where the maximum number of errors
can be detected by the compiler as early in the development process as
possible.  For the most part, in most circumstances, this actually happens.

Full-path, and total testing are simply out of the question for large software
systems.  Therefore, we need to find ways to priortize the testing process
so we focus on those errors with the greatest probability of occurrence as
well as those with the greatest serverity, should they occur.   A testing
strategy needs to be coupled with a risk management policy.   Risk
management, to be truly effective, needs to be based on recorded experience
of the kinds of defects typical of a domain, an organization, etc.  With some
knowledge of the frequency distribution of errors, we can then develop a
sensible testing strategy.   For example, if we know that a certain programmer
always makes mistakes of a certain kind, we can focus more testing on his
programs.  If we know that a certain category of mistakes occurs at a
given stage of projects of the kind we are developing, we can create a
strategy for evaluating software at that stage.

Strategies for testing are important since there is no way to test all the paths
of any program.   Design strategies that take advantage of the error reporting
from a compiler are important so we will not have to test those errors that
are reported.   Inspection strategies are essential for identifying the kind of
errors that are most easily spotted by a well-trained human.     All of these
are important, even when using Ada.

Richard Riehle