Re: C/C++ knocks the crap out of Ada

[Alan Brain <aebrain@dynamite.com.au>]

bobduff@world.std.com (Robert A Duff) wrote:

>I understand and agree with that.  There are lots of folks going around
>denying that they themselves put bugs in their code, so where does all
>this buggy software I use every day come from !?  But that's not the
>*only* thing I see in this thread.  I also see some bogus claims about
>how Ada will walk on water and raise the dead.

Guess I've been guilty of this latter in the past - at least, according to 
many people who should know.

I find myself in a quandary though: unlike a lot of the contributors, I've 
actually worked with multiple Ada projects, and multiple C projects, and 
even more projects that were mixed. And the results I reported were the 
ones actually experienced. e.g. one case where a fault in the design of a 
CPU caused problems that the Ada run-time checks were able to detect, even 
though the fault caused essentially branches to random parts of the 
memory. In theory, of course, no language could cope with such a 
situation 'absolutely and at all times': in practice though, it could and 
did cope with it for months. 'Cope' is the word. Abnormal functionality, 
slow functionality, hiccups, but nothing fatal. In Practice, with 
sufficient error-checking, it doesn't matter that something really, really 
nasty happens for a short time: the error will soon grow so huge in 
ramifications that an inconsistency will be detected ( ie in C a Coredump) 
and you can rewind. Yes, it requires programmers who know what they're 
doing, the facilities in Ada 83 are NECCESSARY but not SUFFICIENT in the 
mathematical sense of the terms.

Our metrics showed a good rule-of-thumb was that 5% of CPU time was 
'wasted' doing error-checks, assuming pragmas in place for letting the 
compiler optimise out impossible cases. I forget what the ratio was when 
no optimisation was performed - 15% sounds about right, but don't quote 
me. I always preferred the latter though, as forex the 'branch randomly' 
error adduced above would not have been caught and worked around so easily 
(easily he says, HA! it was farnarckling painful) without it.

I always have a cold shiver when I hear that 'of course we pragma'd out 
the run-time checking in the production system'. 5% better performance is 
generally not that critical - if it is, start reaching for a new CPU, as 
the additional functionality you're gonna need in the maintenance phase 
will eat that up in a week or two.

FYI the chip was the d-stepping of the i860 , rev 4, the error occurred 
when paging was enabled, caching was enabled, and an integer was loaded 
into the floating-point processor within 16 instructions of an operation 
on it, and where an interrupt occurred. It clobbered the interrupt return 
address register, so you'd return pretty much anywhere...

I get the feeling whenever I make such a 'walk-on-water' outrageous claim, 
'Ada 83 (helps to) Solves Chip Design Fault!' I'd better give 
Chapter-and-Verse, as above. Yet it did happen, what am I to do, claim it 
didn't, just to add credibility?