Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

From: Marin David Condic (nobody_at_noplace.com)
Date: 02/12/04 

Date: Thu, 12 Feb 2004 12:49:15 GMT

Ole-Hjalmar Kristensen wrote:
>
> Yes, but there are some caveats. Ada insists on getting floating point
> arithmetic "right", so it will typically do it differently than C,
> even though the Ada and C programs superficially look the same. For

Well, I *did* say that only if you had similarly coded examples could
you hope to do any comparison. Not that you couldn't do a comparison and
see a difference. ;-)

Secondly, one needs to insist that some code under evaluation must
produce a *correct* result. If a C coded example computes the wrong
answer at twice the speed of a similar Ada example that gets the answer
right, is it even worth discussing?

My final objection to the whole "Benchmark Wars" is that for 90% of the
uses of compilers, it just plain doesn't matter. If I build a program to
solve a matrix and it gets me an answer displayed on my screen in 10
seconds - but I re-code it in another language and the answer pops up in
8 seconds instead, what am I going to do with those extra two seconds?
Save them up for Christmas? People do this sort of math stuff all day
long in spreadsheets which are interpreting the answers at great
inefficiency and they spend lots of time not caring about it. So why do
programmers without a real performance constraint spend so much time
getting their panties in a bunch over something that never has a real
impact on what they're doing?

Keep in mind that I work with apps where miliseconds count, so I know
how to worry about compiler efficiency. I also know I can get good
compiler efficiency out of Ada (plus all of Ada's other benefits), so
when I *must* be efficient, I know I can get there. But when I go over
to a PC or workstation to develop some hacker tool I need, worrying
about a few extra CPU cycles is way down on my list of concerns.

Too many people spend too much time agonizing over "Compiler Efficiency"
- usually without any real scientific data to back up their perceptions
of what is fast and what is slow - and most of the time it just plain
doesn't matter. I'd bet that if we took most of the applications that
people use on a daily basis and inserted random delay statements
throughout them to double the amount of CPU cycles they use, nobody
would notice any difference in how they got their job done.

MDC 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm
Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r
     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."
         --  Al Bundy
======================================================================