Re: Bug in Ada (SuSe 10.2) ?

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

"Alex R. Mosteo" <amosteo@unizar.es> wrote in message
news:624tidF21i3nvU2@mid.individual.net...
> tmoran@acm.org wrote:
...
> >    More importantly, how many times have we seen postings here from
people
> > new to Ada saying "I heard about Ada, this supposedly highly safe
> > language, but it doesn't even catch an overflow, though the manual
claims
> > it does."?  vs How many times have people new to Ada posted messages
> > asking about some obscure compiler bug they've stumbled across.
>
> vs How many times "my number-crunching program is horribly slow, in
> fortran it was lightning fast"?
>
> I /believe/ this has happened maybe once or twice in the last lustrum,
> for sure not enough to justify not having -gnato by default.

I don't think (at least on the Intel hardware) that -gnato has much to do
with the speed of floating point operations. They're much more dependent on
the cost of range checks, the rules that prevent rearrangements if
exceptions can be raised, and the Ada accuracy rules. All of which can be
worked around, but that requires more effort than simply changing some flag
on the command line.

Moreover, the code that is speed-critical is always a small part of any
program. It is bad practice to turn off checks everywhere simply so that a
small piece of code will run faster. It's simply premature optimization.

Now, I realize that some people run benchmarks without any tuning, and use
that to claim that some implementation of some language is "slow". (Or
worse, make the claim that the entire language is "slow", forgetting that
implementations can vary widely.) We could combat that by turning off all
checks by default and by letting optimizers rearrange code in any way that
they like and so on. But the result would have none of the values of Ada. Is
that really the only way to sell Ada?

The important thing is that tuned Ada code can be as fast as tuned C code
(or tuned Fortran code), not whatever happens by default. People usually are
comparing raw Ada code to tuned C and Fortran code anyway -- what do you
*think* is going to happen?

If the only way to sell Ada is to make it more like C, then we've already
lost. Customers sold Ada that way won't gain any of the benefits of using
Ada, and are likely to end up thinking they were sold something that is more
hype that results. That's not going to help Ada in the long run (or even the
medium run), although it might help someone's bottom line for a while.

Thus, I conclude if omitting language-defined checks is that important to
selling an Ada compiler, there is no hope for Ada. We all should find
something more useful to do.

                                       Randy.