Re: ADA Popularity Discussion Request

["Randy Brukardt" <randy@rrsoftware.com>]

"jayessay" <nospam@foo.com> wrote in message
news:m3wtz7e4hd.fsf@rigel.goldenthreadtech.com...
> kevin.cline@gmail.com (Kevin Cline) writes:
...
> > 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.
>
> Exactly.  Actually this sort of development will save you much more
> time and money than you could ever hope for from typical static typing.

This seems like complete nonsense to me. (I'll admit that I've read other
people making similar claims). The reason is that writing a good subprogram
test takes on average 10 times as much code as is in the subprogram itself.
That's because of the need to set up the needed global state for the
preconditions, and the need to test all of the possible permutations of
input. Making the test reusable and automatible adds even more effort.

The best way to save time and money is to avoid the need to do that testing
in the first place. We do that with Ada's strong compile-time and run-time
checking, combined with occassional invariant assertions. And then we do
extensive, repeatable system-level testing to find any logic errors. Our
experience is that true logic errors (those that doesn't show up as
compile-time or run-time checks) are very rare, probably less than 1% of all
errors. (I'm omitting interfacing errors from this summary, because there
you lose all benefits of Ada or for that matter any type system, even one as
weak as C's. No language is going to help you there, but the real world is
always going to insist on it...)

If I had a stronger need for correctness, I'd move to something like SPARK,
and do *all* of the checking at compile-time; I certainly wouldn't write
more tests.

                                  Randy.