Re: ADA Popularity Discussion Request

[Jeffrey Carter <spam@spam.com>]

Kevin Cline wrote:

> I've come to the same conclusion.  Once you decide to test code before
> you write it, strong typing loses most of it's value.  On the other
> hand, if I'm working on code without a good set of automated tests,
> then strong typing is a very nice thing to have.

For software of typical complexity, testing sufficient to prove the 
absence of errors takes longer than the allowable schedule for any 
project I've ever worked on. Testing in the real world cannot be counted 
on to find all errors.

Since testing cannot be counted on to catch all errors, anything else 
that finds errors may catch errors that testing will miss. There is a 
synergy between the Ada features that find errors during compilation (of 
which strong typing is only one) and testing.

It is a documented fact that errors cost less to fix the earlier they 
are found, so errors found during compilation save money compared to 
those found during testing.

The cost of fixing an error is proportional to the time spent making the 
correction, so errors found during compilation take less time to fix 
than those found during testing. If time to market is a concern, using a 
language that finds more errors during compilation will decrease the 
time to deployment.

The facts do not support a claim that testing is as time or cost 
efficient as detecting errors during compilation.

-- 
Jeff Carter
"To Err is human, to really screw up, you need C++!"
St�phane Richard
63