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

[Jerry Coffin <jcoffin@taeus.com>]

In article <Xns948AC8C8E553Ejimmaureenrogers@204.127.36.1>, 
jimmaureenrogers@att.net says...

[ ... ]

> I think you will find, if you look into hard real-time systems,
> that performance is critical.

I've looked.  It's usually not.  For real-time systems, the primary 
requirement is usually for absolute predictability, NOT for maximum 
performance.

> While it is true that GNAT has
> produced relatively slow executables in the past, those same
> executables are often 3 to 5 times faster than early Java
> programs. I know that current JVMs have improved performance
> significantly. I speak of JVMs from around the year 2000.

Using Java as a standard of comparison is a tacit admission of a major 
problem.

> Other
> Ada compilers produce faster code than GNAT. Sometimes you get
> what you pay for. (GNAT is a free compiler in the GNU compiler
> chain).

The last time I checked, GNAT uses the same back-end as the other GNU 
compilers, so if it doesn't produce as good of code, it's a strong 
indication of a performance problem in the language proper.
 
> What kind of performance measures do you use in your problem
> domain? C programmers are fond of fast code execution and fast
> compilation. C++ programmers have similar performance priorities,
> but are willing to sacrifice some compiler speed for the
> flexibility of templates. Java programmers frequently prize
> speed of coding, with the clever use of the large set of API
> libraries available to them. Ada programmers are fond of fast
> code and early detection of coding defects.

Any statement that attempts to characterize all C++ (or Java or Ada) 
programmers as having the same priorities as each other is bound to be 
false.

Worse, there's a tendency to overcompensate for perceived weaknesses at 
the expense of perceived strengths.  Thinking of error reporting as a 
weakness, many C++ programmers frequently put tremendous work into it.

Conversely, many C++ programmers take execution speed so much for 
granted that they write horribly inefficient code on the assumption that 
the compiler can (and will) make up for whatever they do.

Though I don't work with as many Ada programmers on as regular a basis, 
it appears to me that many do more or less the opposite: it's so widely 
assumed that the compiler will catch almost all errors, that many 
blithely assume that almost anything that compiles MUST be correct.  At 
the same time, execution speed has been perceived as a problem often 
enough that many knowingly and intentionally subvert type-checking and 
such, on the assumption that it's necessary to get the speed they think 
they need to be competitive.

Without trying to take this too far, the result is that in _many_ cases, 
what are widely perceived as strengths or weaknesses of particular 
languages often end up being almost exactly the opposite of what's 
really the case.  In the end, nearly all the factors being discussed 
depend far more on the programmer than the language, so complacency is 
common but rarely justified.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.