Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[smize@news.imagin.net (Samuel Mize)]

In article <slrn5rn570.j6j.abo@minkirri.apana.org.au>,
Donovan Baarda <abo@minkirri.apana.org.au> wrote:
>One of the things that can make Ada pretty inefficient is its pass by copy
>mechanism. This means that 'in out' parameters have to be copied twice,
>once on calling the procedure, and once again on return. I believe that it
>can add extra overheads even for 'in' and 'out' parameters. For large
>array parameters, this can be a killer.

Sorry, this is erroneous.  Ada's "in out" parameters can be passed by
copy OR by reference, as appropriate for efficiency.  Ada 95 provides
specific rules to make the behavior a little more predictable, but
pass-by-reference is certainly available for anything larger than
a pointer.


>The biggest problem with Ada compared to C, is the language is so complex.
>The compiler writers have such a hard time just getting it to work that
>they hardly get around to putting in optimisation. C is so small that
>compiling it is easy, so more effort gets spent on optimization. 

Ada 83 compiler vendors did use this excuse, but Ada 95 brought the ACT
people and some other skilled compiler vendors into the Ada domain.  You
can now get inexpensive Ada compilers that optimize very well -- certainly
well enough for real-time flight simulators, for example (with full flight
dynamics, complete cockpit and out-the-window graphics, I mean -- we're
not talking Microsoft Flight Simulator here).


>I find it hard to believe that there are people who advocate Ada purely on
>language merits. As a language, Ada sucks.
...
>Where Ada wins is in a combination of language merits...

Interesting perspective.

You might check out the advocacy materials at http://www.adahome.com, if
you want to see why people advocate the use of Ada.  Here's a quick take:

I would advocate Ada for traditional or object-oriented development tasks
with any of the following characteristics:
* large scale (large team, or a small team for a long duration)
* high reliability required
* multiprocessing needed
* tight real-time requirements
* reusing a lot of "legacy" code

When would I *not* use Ada?  Well, for a graphical user interface, I
wouldn't use *any* language directly, I'd use a UI tool.  For some
database programs you can use a "fourth-generation" language (a tool
that generates the UI and the supporting query language).  For logic,
functional or data-flow programming, you need a specialized language.
For a rule-based expert system, you'd use an expert system shell.

Some people in the object-oriented world prefer other languages, but
most of these haven't had/made a chance to evaluate Ada 95's tagged
types yet.  Certainly for a mixed object/functional development
approach, Ada hammers the opposition.

Note also that there are UI tools and expert system shells that
use Ada as their implementation language.

But I'm not arguing that you should like Ada, just that it isn't
a bad choice.  Preference are inarguable.

Sam Mize

-- 
Samuel Mize -- smize@imagin.net -- Team Ada
(personal net account)