Re: ADA Popularity Discussion Request

["Richard Riehle" <adaworks@earthlink.net>]

"Benjamin Ketcham" <bketcham@drizzle.com> wrote in message
news:1094529422.982635@yasure...
> Richard  Riehle <adaworks@earthlink.net> wrote:
> >
> > 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.
>
> While I agree with the overall point here, I keep seeing this
> assertion, here made with especially great conviction: "it is
> impossible to test for the unexpected".  As with many absolute
> statements, it is not technically correct, although it expresses
> a valid general truth.  Consider the method of kernel testing
> where system calls are invoked with random arguments; this kind
> of test often turns up "unexpected" problems.

Yes, Benjamin, I may have been a little too over the top in
my use of the word, "impossible."   I too have seen test plans
and test scripts that randomly traverse that entire universe of
possibilities to make sure that none of the unwanted combinations
of keyboard entries (or other data sources) are allowed to pass
at run-time.

One of the benefits of assertions (DbC) is that one can simply
declare a range of unacceptable conditions as part of the design
and be assured that those conditions will not be permitted to
occur.

Even so, whether programming with assertions, or using a test-driven
approach, one needs to be a little careful about depending too much
on the tests or the assertions.   Moreover, a well-designed program
must be about more than simple correctness, even as hard as that
is.

Much has been said, in this forum, about the wonders of test-driven
design in dynamically-typed languages as a benefit to on-going change
in a program.   In other forums that deal with this topic, advocates of
TDD include refactoring as one of the mechanisms of choice.   No
reasonable person will deny that, under some circumstances and for
some kinds of software, these are acceptable models of development.
We are always compelled to ask about the limits of any tool, method,
or style.  To answer, "There are no limits," is to consign oneself in the
league of the naive.

Static typing, design by contract, and other static methods are certainly
limited in what they can accomplish.   So too, we must recognize the
limits of the dynamic approach.   As we examine those limits, for
both approaches, we are required to also examine the trade-offs and
risks associated with them.   Is one approach more dependable for
a given domain than the other approach?  Is one more economical than
the other for the context in which it will be used?

This kind of inquiry is not unlike any other engineering exercise.  We
are in pursuit of a predictable outcome, an outcome that satisfies a
defined set of requirements.  Whether those requirements are specified
as the tests themselves (as in TDD), or embedded within the assertions
(as in DbC),  in the type definitions and associated methods, or some
combination, the goal is the same.

Engineering is concerned with design.   Engineeering prefers, as much as
possible, settled knowledge rather than a continual test-debug model.
We try to get the design as close to correct early, even testing parts of
it along the way as we build it.   However, testing every aspect of the
design is not always possible.   In particular, as the deployed design
is required to deal with the real world, it must be able to adapt itself
to the unexpected.

Let me give you an example.   In am system I know something about,
one with a large number of components,  a programmer included a
routine that had a built-in constraint (not a type constraint), in the
form of an if ... end if statement.    The constraint was cleverly
written and the language in use was not strongly typed, so the
programmer could use long (as in long integer) as a reasonable
data type for his algorithmic mischief.    I say mischief because
that was what it was, a small time-bomb intended to crash the
program long after he resigned and went on to another job.

No amount of testing would have caught this. He was clever
enough to see to that.   The design was not type safe, so the
result from his routine could be easily passed to some other
routine as a parameter.   You many argue to the contrary,
but the test scripts (well-designed) did not catch the error.
When it occurred, the system failed, and no one knew why
until a considerable amount of analysis was performed.

Experienced software designers could easily relate many more
such stories.   Engineering history is full of them.  Knowing that,
in the world of physical engineering, where we are constrained
by physics and can measure everything down to very fine
tolerances, and still make disastrous mistakes, how do we justify
any approach to software engineering that limits us to a single
approach to creating dependable software?     This question
is especially important with the increased use of software in
safety-critical systems.

Finally, I truly hope that no Lisp programmer, Smalltalk
enthusiast, or their ilk will persuade the designers of
flight avionics to begin using those languages.   It is bad
enough that some of them have chosen to use C and
C++.   We need to, as always, select the right tool for
the job at hand.

Richard Riehle