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

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

[Steve Jones - JON]

Mukesh Prasad <prasadm@polaroid.com> writes:

> 
> Jon S Anthony wrote:
> > > If I were to do heavy-duty graphics, compression, or image
> > > processing involving implementation of state-of-the-art algorithms,
> > > I would think very carefully before choosing Ada.
> > 
> > Why?
[snip]
> 
> Actually, a rectangle would be a better
> test of Ada's capabilities.  A triangle would
> require you to pick up Breshenham or DDA or
> something, which is not relevant to language
> capabilities as such.  The CGA part, on the
> other hand, is important -- since it shows
> how Ada deals with abnormal programming
> situations.  As long as everything
> was done from first principles, I think 
> this would provide a good test.

This seems a very strange test, for a very paticular enviroment, using
Ada OpenGL bindings I could do it quickly without having to worry about
any coding errors.  There is no implicit speed difference that I have
ever come across in any Ada work I have ever done, certainly the direct
to hardware things I have done or had to interface with have been much
cleaner when done in Ada as opposed to C.

In the area I work (ATC systems) the simulator I currently work on uses
Ada in its entirety, this involves X and PEX work and the displaying of
100s of real time tracks.  This certainly requires alot of processing and
it would not have been quicker in C, I know this as I previously implemented
a system in C using X and PEX.  The difference in timings between the
two systems have nothing to do with the language of implementation but
with the different design aims of those systems.  On basic test programs
C and Ada match each other pound for pound.




-- 
|Un Loup en France  | Wolverhampton Wanderers, out of darkness cometh Bully|
|------------Cat 1, Cha, Cha, Cha -- NERC offical drinking song------------|
|----The above opinions rarely reflect my own and never my employers'------|
|Do not add me to mailing lists violations will be billed for time.        |

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

[Mukesh Prasad]

Steve Jones - JON wrote:

> Mukesh Prasad <prasadm@polaroid.com> writes:
>
> >
> > Jon S Anthony wrote:
> > > > If I were to do heavy-duty graphics, compression, or image
> > > > processing involving implementation of state-of-the-art
> algorithms,
> > > > I would think very carefully before choosing Ada.
> > >
> > > Why?
> [snip]
> >
> > Actually, a rectangle would be a better
> > test of Ada's capabilities.  A triangle would
> > require you to pick up Breshenham or DDA or
> > something, which is not relevant to language
> > capabilities as such.  The CGA part, on the
> > other hand, is important -- since it shows
> > how Ada deals with abnormal programming
> > situations.  As long as everything
> > was done from first principles, I think
> > this would provide a good test.
>
> This seems a very strange test, for a very paticular enviroment, using
>
> Ada OpenGL bindings I could do it quickly without having to worry
> about
> any coding errors.  There is no implicit speed difference that I have

The point was -- if I am implementing OpenGL and I want
to do it in Ada, what are the pluses and minuses?  OpenGL
can be implemented relatively straight-forwadly in C and
most probably was.  Should OpenGL developers have considered
Ada for this task?  (Notice the original comment was that
if you are doing this type of task, you should think carefully
before picking Ada.)

If the basic assumption is that all the "low level" work has been done
by third parties and all that's needed is some glue code, then
maybe the advantages of Ada stand up without needing
more considerations in the metric.  But in that case, perhaps
you need to show how Ada relates to Visual Basic -- C
or C++ would be wrong languages for this particular comparison.

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

[Jon S Anthony]

In article <33A9338D.10BB@polaroid.com> Mukesh Prasad <prasadm@polaroid.com> writes:

> Jon S Anthony wrote:
> > > If I were to do heavy-duty graphics, compression, or image
> > > processing involving implementation of state-of-the-art algorithms,
> > > I would think very carefully before choosing Ada.
> > 
> > Why?
> 
> Well, I must admit that I haven't done anything
> in Ada since 1983, and even then it was small programs.

Well, that isn't even Ada anymore.  ISO Ada => Ada95 since Jan'95, as
implemented in Gnu Ada (GNAT), ObjectAda, etc.


> The impression I recall mostly was that it was
> highly typed (the word I reflexively thought of was
..
> things I would do in C/C++ in implemeting a graphics
> or compression algorithm would be cumbersome
> or difficult to do efficiently.

Nah.  You can actually adopt the same sloppy style if that is what you
want - right down to using the exact same "documentation" for C libs
like X/Motif/Win32/etc.


> you (or anybody else volunteering)
> could post a brief segment on how one
> would scan-convert a triangle and set up
> the bits on a CGA (without taking advantage
> of graphics libraries from vendors -- since

Why?  As I pointed out, it is simple to take advantage of such
graphics libs or any other for that matter.  I'm not a real UI type,
and have only written interfaces with Ada using X/Motif and Java AWT
(yes, you can directly write Java apps in Ada and use the various AWT
commercial packages out there).


> vendor libraries are in place.)  Let us say
> the platform is basic MSDOS (where C was

Other people have certainly done this.  There is even a free package
that comes with the DOS version of GNAT.  But, to be fair, I have
never really done any DOS programming.


Tell you what - since I'm not a real graphics whiz, it would be much
simpler if you were to post some code showing the so called "difficult
bits" so that it can be translated and shown to be about the same in
Ada.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

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

[Mukesh Prasad]

Jon S Anthony wrote:
> > If I were to do heavy-duty graphics, compression, or image
> > processing involving implementation of state-of-the-art algorithms,
> > I would think very carefully before choosing Ada.
> 
> Why?

Well, I must admit that I haven't done anything
in Ada since 1983, and even then it was small programs.

The impression I recall mostly was that it was
highly typed (the word I reflexively thought of was
"regimented", but that is not an accurate
description for language features,) so many of the
things I would do in C/C++ in implemeting a graphics
or compression algorithm would be cumbersome
or difficult to do efficiently.

But assuming you are current in Ada, and
if you wish to dispel the notion that
such work is easier in C/C++, perhaps
you (or anybody else volunteering)
could post a brief segment on how one
would scan-convert a triangle and set up
the bits on a CGA (without taking advantage
of graphics libraries from vendors -- since
in C/C++ much of such work happens even before
vendor libraries are in place.)  Let us say
the platform is basic MSDOS (where C was
actually used heavily in 80s
for much low-level graphics work).

Actually, a rectangle would be a better
test of Ada's capabilities.  A triangle would
require you to pick up Breshenham or DDA or
something, which is not relevant to language
capabilities as such.  The CGA part, on the
other hand, is important -- since it shows
how Ada deals with abnormal programming
situations.  As long as everything
was done from first principles, I think 
this would provide a good test.

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

[Robert Dewar]

Mukesh says

<<But assuming you are current in Ada, and
if you wish to dispel the notion that
such work is easier in C/C++, perhaps
you (or anybody else volunteering)
could post a brief segment on how one
would scan-convert a triangle and set up
the bits on a CGA (without taking advantage
of graphics libraries from vendors -- since
in C/C++ much of such work happens even before
vendor libraries are in place.)  Let us say
the platform is basic MSDOS (where C was
actually used heavily in 80s
for much low-level graphics work).>>


This sounds trivially easy to do in Ada, so perhaps we are missing something.
To make sure we are not, post the C code that represents what you are trying
to do (or rather see how Ada could do).

If you have not used Ada since 1983, then that's a bit like saying you
have not voted since you were 18, since 1983 was the year that the Ada
language was standardized, and it took many years before really capable
compilers were available, so your experience provides no clue at all really.

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

[Tim Harrison]

In article <33A9338D.10BB@polaroid.com>, prasadm@polaroid.com wrote:

> Jon S Anthony wrote:
> > > If I were to do heavy-duty graphics, compression, or image
> > > processing involving implementation of state-of-the-art algorithms,
> > > I would think very carefully before choosing Ada.
> > 
> > Why?
> 
> Well, I must admit that I haven't done anything
> in Ada since 1983, and even then it was small programs.

Enough said...Perhaps someone with Ada experience would be better suited
to answer this question.
-- Tim Harrison <harrison@acm.org>

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

[Kaz Kylheku]

In article <harrison-2106970827440001@apm1-87.realtime.net>,
Tim Harrison <harrison@acm.org> wrote:
>> Well, I must admit that I haven't done anything
>> in Ada since 1983, and even then it was small programs.
>
>Enough said...Perhaps someone with Ada experience would be better suited
>to answer this question.
>-- Tim Harrison <harrison@acm.org>

According to some of the material I have read via the adahome WWW page,
Ada allegedly had a ``bad'' reputation for poor performance due to an early
batch of compilers that didn't generate very good code. But that was fifteen
years ago.

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

[John Goodsen]

Tim Harrison wrote:
> 
> In article <33A9338D.10BB@polaroid.com>, prasadm@polaroid.com wrote:
> 
> > Jon S Anthony wrote:
> > > > If I were to do heavy-duty graphics, compression, or image
> > > > processing involving implementation of state-of-the-art algorithms,
> > > > I would think very carefully before choosing Ada.
> > >
> > > Why?
> >
> > Well, I must admit that I haven't done anything
> > in Ada since 1983, and even then it was small programs.
> 
> Enough said...Perhaps someone with Ada experience would be better suited
> to answer this question.
> -- Tim Harrison <harrison@acm.org>

I would point you to probably one of the most powerful CAD products on
the market today, called CADWIN, developed by a Paris company,
Strategies.  
This product excels at high-performance 3D CAD applications and is
written
entirely in Ada.  Strategies chose Ada some 10 years ago as a strategic
decision and that choice now pays off.  From a performance and usability
standpoint, CADWIN wins hands down against older, archaic graphics
products
like AutoCAD, etc...  I know - I've compared them and watched many users
make the choice ... you haven't heard of CADWIN because they don't try
to compete in the highly competetive, pile-o-marketing-lies CAD market,
but rather, we use this technology to provide custom solutions for
clients,
with more work than we can already handle via referrals ...

Furthermore, the Ada Graphics Toolkit used to develop the CADWIN family
of products is also available for license to customers who need
powerful,
high performance graphics.  This toolkit, called Heragraph, also
provides
cross platform GUI components (lists, tabs, fields, comboboxes, etc.) so
you build your graphics application one time and it recompiles and runs
on other platforms (most Unix/X flavors, Windows, Windows95, WindowsNT).

Semd email directly to me if you would like more information on
Heragraph
and the CADWIN family of Ada based graphics products, in the U.S.
market.

-- 
John Goodsen              Saguaro Software, Inc. 
jgoodsen@saguarosoft.com     User Centered Object-Oriented Design
Specialists
http://www.saguarosoft.com   Object-Oriented S/W Architecture, Process,
Methods
602.706.1056                 Software Engineering Tools and Training

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

[Michael Levasseur]

Hello,

If by the term "Graphics" you mean making up commands to draw
Graphical Primitive objects on a screen, i.e. Lines, Points or
Polyline; then Ada is as good as C. Depending on the "Graphics
Engine" and the command language used. I've used Graphics Engines
the used GKS or PEX commands to control the Graphics Engine.

Most of the Graphics Engines I've used were written in C or Assembly
language inorder to gain the most speed that the hardware can supply.
I don't know of any Graphics Engines that were written in Ada.
This is probably due to the fact that EVEN DoD companies, usually
buy a commercial Graphical Engine rather that creating their own.

If by "Graphics" you are refering to "Graphical User Interface",
then I've seen numerous very good GUIs that were written in Ada.
It's not quite as easy to write a GUI in Ada 83 as it is to
write the same GUI in C++. The Ada GUI though will probably be
smaller in code size than the C++ GUI.

My choices on the three would be:

Graphical Engine Code written in C for maintainability and speed.

Graphical Application written in Ada 83 or Ada 95 for maintainability,
reliability, and to keep my customers happy (DoD).

GUI written in C++ for easy of developing. 
(As long as my Code Size creap doesn't kill me :-) )

This is all just my $0.02.....

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

[Chris Brand]

Michael Levasseur wrote:
> 
[snip]
> 
> Most of the Graphics Engines I've used were written in C or Assembly
> language inorder to gain the most speed that the hardware can supply.
> I don't know of any Graphics Engines that were written in Ada.
> This is probably due to the fact that EVEN DoD companies, usually
> buy a commercial Graphical Engine rather that creating their own.
> 
[snip]

One project I worked on briefly considered an implementation of Xwindows
in Ada (by a French company, IIRC). We never got as far as evaluating
it, though, so I can't comment on the speed.

It's also possible that it was just the client software, not the X
server itself. I can't remember.

-- 
Chris
Stating my own opinions, not those of my company.

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

[Matthew Heaney]

In article <33B16CBB.417A@gdesystems.com>, Michael Levasseur
<levass@gdesystems.com> wrote:


>My choices on the three would be:
>
>Graphical Engine Code written in C for maintainability and speed.
>
>Graphical Application written in Ada 83 or Ada 95 for maintainability,
>reliability, and to keep my customers happy (DoD).
>
>GUI written in C++ for easy of developing. 
>(As long as my Code Size creap doesn't kill me :-) )

I'm curious: on what basis would you consider C superior to Ada for
"maintainability and speed"?  What about Ada do you think is responsible
for its being not as fast as C?  Have you benchmarked some code in order to
make a comparison?

It is my understanding that because of Cs aggressive use of type-casting,
optimizations are actually more difficult to make than in Ada, where more
semantic information is given to the compiler (because of the richness of
its type system), thus allowing better optimization than is possible for C.

In Ada, the type system is merely a tool, and of course the programmer can
use it or not use it as is his desire; most _choose_ to turn on  strong
typing, though certainly that isn't required by the language.  It would be
very simple to just use the numeric types that come predefined in Ada, thus
allowing you to do the same sort of loosely-typed programming that one does
in C.

And I've fallen into the little trap there of assuming the stronger typing
is somehow less efficient.  Yes,  there are checks to make sure that I
don't dereference an item beyond the end of an array, for example, but for
the most part programmers feel these checks are beneficial, and are quite
happy about not being able to clobber memory accidently.

Note too that these range checks occur only when the compiler is unable to
determine that the range of the index object lies within the range of the
array index subtype.  When the index object is more strongly typed, this
gives the compiler the information it needs to turn array index checks off! 
Thus the idea that strong typing is less efficient is largely a myth.

And even then, in spite of a strongly-typed infrastructure, the Ada
programmer has an escape hatch called Unchecked_Conversion, to allow him
the freedom to convert any kind of type into any other kind, with the same
semantics as in C using type casts.

That C is more maintainable than Ada: again, on what basis?  Better
maintainability would imply that one can more easily understand the code,
by being able to focus on a small part at a time.  This a made possible by
Ada (and other languages) by providing a facility to create
programmer-defined abstractions, a facility largely missing in C (when
compared to other langauges).

So I'm confused by the argument that C is "faster" and "more maintainable"
than Ada.  Perhaps you would care to eludicate your reasons for believing
so.  Do you have a (small) code example in C that demonstrates why you feel
C is superior to Ada for writing a graphical engine?  Perhaps we could then
come up with an equivalent Ada example to show that Ada is not any less
efficient or less maintainable.  We might even be able to show that the Ada
example is faster, and more  
maintainable.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

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

[Donovan Baarda]

On Wed, 02 Jul 1997 21:42:31 -0800, Matthew Heaney <mheaney@ni.net> wrote:
>In article <33B16CBB.417A@gdesystems.com>, Michael Levasseur
><levass@gdesystems.com> wrote:
>
>
>>My choices on the three would be:
>>
>>Graphical Engine Code written in C for maintainability and speed.
>>
[snip]
>I'm curious: on what basis would you consider C superior to Ada for
>"maintainability and speed"?  What about Ada do you think is responsible
>for its being not as fast as C?  Have you benchmarked some code in order to
>make a comparison?
>
>It is my understanding that because of Cs aggressive use of type-casting,
>optimizations are actually more difficult to make than in Ada, where more
>semantic information is given to the compiler (because of the richness of
>its type system), thus allowing better optimization than is possible for C.
>
True. It is not just C's loose typing that makes it hard to optimize.
However, Ada is not such an easy language to optimize either.

[snip]
>That C is more maintainable than Ada: again, on what basis?  Better
>maintainability would imply that one can more easily understand the code,
>by being able to focus on a small part at a time.  This a made possible by
>Ada (and other languages) by providing a facility to create
>programmer-defined abstractions, a facility largely missing in C (when
>compared to other langauges).
>
I would probably agree that Ada is slightly more readable than C, and
definitly more mantainable. Readability and mantainability are IMHO not
the same thing. Readability is how easy it is to understand a program from
the source code. Mantainability is how easy it is to safely modify and
update a program during its life time.

>So I'm confused by the argument that C is "faster" and "more maintainable"
>than Ada.  Perhaps you would care to eludicate your reasons for believing
>so.  Do you have a (small) code example in C that demonstrates why you feel
>C is superior to Ada for writing a graphical engine?  Perhaps we could then
>come up with an equivalent Ada example to show that Ada is not any less
>efficient or less maintainable.  We might even be able to show that the Ada
>example is faster, and more  
>maintainable.
>

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.

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. 

I find it hard to believe that there are people who advocate Ada purely on
language merits. As a language, Ada sucks. It is probably better for
large projects than C, but then C is only a small step above assembler. In
just about any application you can think of, there are languages better
than Ada for the task.

Where Ada wins is in a combination of language merits, available 
compilers, supporting tools, and market penetration and demand (DOD).
Mainly $$$ for programmers :-)

ABO

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

[Matthew Heaney]

In article <slrn5rn570.j6j.abo@minkirri.apana.org.au>,
abo@minkirri.apana.org.au (Donovan Baarda) 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.

I think there's a misunderstanding here.  The language only mandates that
scalar types and access types be passed by copy, and the RM makes it clear
that the implementation is free to choose the mechanism (ie by reference)
for arrays and records.

>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. 

I asked Robert Dewar, the principal developer responsible for GNAT (a free
Ada compiler that targets the gcc), a similar question about Ada's putative
complexity, and he responded that it wasn't the front end that was the hard
part, it was the back end.

So it would appear that at least one compiler vendor _does_ spend a lot of
time on optimization.

Also, at least a couple of other compiler vendors in the real-time market
have purchased Intermetric's Ada-Magic front end, so that they too can
spend their time on optimization, because they were able to buy the front
end off the shelf.

So again, I am confused by the comment that "compiler writers don't have
time to optimize the code," because there is ample evidence to the
contrary.  For which compiler writers specifically is this the case?

>I find it hard to believe that there are people who advocate Ada purely on
>language merits. As a language, Ada sucks. It is probably better for
>large projects than C, but then C is only a small step above assembler. In
>just about any application you can think of, there are languages better
>than Ada for the task.

Having programmed in C, Fortran, and Ada, my personal experience with Ada
has been quite positive.  In Ada, I am able to specify records for external
device I/O with a precisely defined layout, am able to write date
structures that I can use for any assignable type, have multi-threading
built into the language, etc, none of which I can do in C.

Don't get me wrong, I like C, but my experience is that Ada is a much more
expressive language, and I am much more productive as a result.

Perhaps you could provide an small code example of why you think that Ada
"sucks."  On what specific basis are you making this statement?

I ask because I am interested in learning more about C and other languages,
and so maybe there is some feature that these other languages have that Ada
doesn't have, that I am unaware of.

One application I can think of, and which I've had a some experience with,
is with real-time embedded applications.  I can say that having done it
both in C and Ada, my  preference is for Ada.

Another application is in safety-critical applications such as railroad
control and air traffic control, for which Ada is very highly suited.  In
fact, Ada is the language of choice for such systems.  (Visit the Ada home
page, <http://www.adahome.com> , for a list of many companies writing Ada
software for this domain.)

Another application is in information systems, for which Ada 95 and support
for the Information Systems annex would seem to be a very good language.

So again, I am confused about by the comment that "in any application you
can think of, there are better languages than Ada," because there are
applications for which Ada seems like the ideal choice.  Perhaps you can
list a few applications (AI?) for which there are better languages than
Ada, and provide specific reasons why you feel those other languages are
more suitable.

I wish to improve myself as a software engineer, and would like to learn
what you know about domains and applications for which Ada is not the
preferred language.

>Where Ada wins is in a combination of language merits, available 
>compilers, supporting tools, and market penetration and demand (DOD).
>Mainly $$$ for programmers :-)

I think the DOD would prefer you use Ada, but the DOD does not mandate
Ada's use.  As a contractor to the government, you are free to use whatever
language you feel is most appropriate (in the context of a systems
engineering analysis).  That there is no mandate for the use of Ada should
be interpreted to mean that Ada is a strong enough language that it doesn't
require a mandate.

Note too that the idea that Ada is "used for military applications only" is
a myth.  There many safety-critical systems - not military in any way -
written in Ada.  For example, the Boeing 777 is an all-Ada system.  

What language do you feel is better than Ada for safety-critical systems? 
Can you explain what features that language has that makes it so?  I would
like to learn what you know about safety-critical applications.

Also, I'm not sure what you mean by the comment that Ada is good because it
means "more money for programmers."  As a consultant, my fee is the same
for Ada, C, C++, Java, or whatever other language you ask me to use.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

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

[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)

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

[Brian Rogoff]

On 4 Jul 1997, Donovan Baarda wrote:
> On Fri, 04 Jul 1997 00:16:15 -0800, Matthew Heaney <mheaney@ni.net> wrote:
> whoa, I never intended to spark another language war, but I guess I asked
> for it with that last paragraph :-)

They're a fact of newsgroup existence, like the weather.

> But the language complexity doesn't just impact the front end, it also
> makes the back end harder as well. In the case of GNAT, I belive they
> started with the gcc backend, but had to modify it to meet Ada's specific
> requirements. Many other compilers for more compact languages manage to
> use the gcc back end unchanged.

No, the gcc backend is (was?) C specific, and other languages like Fortran
77 also require changes (in particular to handle aliased arrays). The
changes that make it into gcc are those which can do the greatest good for
the greatest number of languages.

> I'd be interested in knowing if the effort spent on the back end was
> actualy improving optimization, or just trying to shoe-horn Ada into it.
> The gcc back end already has pretty impressive optimisation.

I wonder how g77 users regard the level of optimization compared to 
a good Fortran compiler?

> Granted, Ada is better than C or Fortran for most applications. But there
> are other languages that do it better. However, before I get into a
> your-gol vs my-gol discussion, I should point out that it is easy to
> invent a new language that is "better" than any other language for a
> variety of reasons (especialy with the benefit of hindsite). It is much
> harder, and more significant, to get that language into widespread use.

I agree that Ada sucks, but I think all current computer languages suck in 
one way or another. Language choice is a minimization-of-suckfullness
problem with lots of variables. I think Ada 95 is reasonable solution for 
some problems for now. 

> Now back to the language war :-)
> 
> Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
> does in 40 reserved words and 81 syntax rules. The only things missing
> from modula-2 that are in Ada are generics, exceptions, and operator
> overloading. However, it makes up for these deficiencys by having late
> binding (through procedure variables) and a neater, cleaner, simpler 
> syntax.

The only things missing are GENERICS, EXCEPTIONS, and operator overloading?
Sorry, no generics makes a statically typed language lame. I can do without 
language minimalism myself. In fact I even wish Ada had user defined
operators like Algol 68! I agree that Ada would be better with Pascal style 
procedure parameters, but you can fake them with generics or (to be
compiler-specific) with Unrestricted_Access in GNAT.

> Feature counting alone is not enough to gauge the technical merits. Too
> many features can also compromise a language. The thing to aim for is the
> minimum number of features required to cover the maximum number of
> target applications most comfortably.

Its still not a well-posed problem, and intelligent people will disagree 
on what is "good". Lots of people think that OO is mostly BS and would 
prefer languages based on genericity, higher order functions, and such. 

The rest of this is an ad for Eiffel, which Donovan seems to like, but 
which, IMHO, also sucks.

-- Brian

PS : Before the Eiffel jihad returns fire, I'll add that Eiffel does
     not suck nearly as much as many popular languages :-) 
     

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

[Donovan Baarda]

On Fri, 04 Jul 1997 00:16:15 -0800, Matthew Heaney <mheaney@ni.net> wrote:
>In article <slrn5rn570.j6j.abo@minkirri.apana.org.au>,
>abo@minkirri.apana.org.au (Donovan Baarda) wrote:
>
whoa, I never intended to spark another language war, but I guess I asked
for it with that last paragraph :-)

>>One of the things that can make Ada pretty inefficient is its pass by copy
[snip]
>I think there's a misunderstanding here.  The language only mandates that
>scalar types and access types be passed by copy, and the RM makes it clear
>that the implementation is free to choose the mechanism (ie by reference)
>for arrays and records.
>
You are right. However, IMHO, this raises another hairy issue of the
language behavior being undefined since pass by copy and pass by reference
are semanticly different when parameter aliasing kicks in. For example;

procedure mung(R:in out matrix;A:in matrix) is
begin
  R(1,1):=R(1,1) + A(1,1);
  R(1,1):=R(1,1) + A(1,1);
end mung;

mung(M,M);

the book I've got says that programs that depend on the mechanism used are
erroneous. I would take a bloody good compiler to raise an error on a
program that does it.

>>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. 
>
>I asked Robert Dewar, the principal developer responsible for GNAT (a free
>Ada compiler that targets the gcc), a similar question about Ada's putative
>complexity, and he responded that it wasn't the front end that was the hard
>part, it was the back end.
>
But the language complexity doesn't just impact the front end, it also
makes the back end harder as well. In the case of GNAT, I belive they
started with the gcc backend, but had to modify it to meet Ada's specific
requirements. Many other compilers for more compact languages manage to
use the gcc back end unchanged.

>So it would appear that at least one compiler vendor _does_ spend a lot of
>time on optimization.
>
I'd be interested in knowing if the effort spent on the back end was
actualy improving optimization, or just trying to shoe-horn Ada into it.
The gcc back end already has pretty impressive optimisation.

>Also, at least a couple of other compiler vendors in the real-time market
>have purchased Intermetric's Ada-Magic front end, so that they too can
>spend their time on optimization, because they were able to buy the front
>end off the shelf.
>
what this also means is the front end is non-trivial, and they were better
off paying someone else a fortune for it than developing their own.

>So again, I am confused by the comment that "compiler writers don't have
>time to optimize the code," because there is ample evidence to the
>contrary.  For which compiler writers specifically is this the case?
>
What I should have said is; given equivalent time and resources, people
developing compilers for simpler languages will be able to put more work
into optimization than people developing Ada.

This statement clearly points to the fact that in the end, Ada will
probably do optimisation at least as good as any other language because
there is more time and resources being put into Ada compiler development.

>>I find it hard to believe that there are people who advocate Ada purely on
>>language merits. As a language, Ada sucks. It is probably better for
>>large projects than C, but then C is only a small step above assembler. In
>>just about any application you can think of, there are languages better
>>than Ada for the task.
>
>Having programmed in C, Fortran, and Ada, my personal experience with Ada
>has been quite positive.  In Ada, I am able to specify records for external
>device I/O with a precisely defined layout, am able to write date
>structures that I can use for any assignable type, have multi-threading
>built into the language, etc, none of which I can do in C.
>
>Don't get me wrong, I like C, but my experience is that Ada is a much more
>expressive language, and I am much more productive as a result.
>
>Perhaps you could provide an small code example of why you think that Ada
>"sucks."  On what specific basis are you making this statement?
>
Granted, Ada is better than C or Fortran for most applications. But there
are other languages that do it better. However, before I get into a
your-gol vs my-gol discussion, I should point out that it is easy to
invent a new language that is "better" than any other language for a
variety of reasons (especialy with the benefit of hindsite). It is much
harder, and more significant, to get that language into widespread use.

My original point was that arguing for your-gol based on language merits
alone is asking for trouble, because sure as chips there's going to be
some-gol out there that does it better. Particularly with a language as
old as Ada. I know Ada 95 is more recent, but bolting OO onto a procedural
language is always a compromise compared to starting with a clean slate.

A more important measure of a languages worth is how many people
understand and use it. Eskimo might be the best language to talk about
snow, but it's no good if there's no one to talk to (Appologys to any
Eskimo's out there). When you start to take this into account Ada starts 
to look pretty good.

Now back to the language war :-)

Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
does in 40 reserved words and 81 syntax rules. The only things missing
from modula-2 that are in Ada are generics, exceptions, and operator
overloading. However, it makes up for these deficiencys by having late
binding (through procedure variables) and a neater, cleaner, simpler 
syntax.

Unfortunatly, Modula-2 and Ada appeared on the scene about the same time.
With little difference between them bar complexity, the DOD mandate faded 
Modula-2 into obscurity. Dispite this, it did briefly have some favor in
Europe, and has been an inspiration for many other languages since. Most
languages that claim inheritance from Ada usualy owe more to Modula-2.

>I ask because I am interested in learning more about C and other languages,
>and so maybe there is some feature that these other languages have that Ada
>doesn't have, that I am unaware of.
>
Feature counting alone is not enough to gauge the technical merits. Too
many features can also compromise a language. The thing to aim for is the
minimum number of features required to cover the maximum number of
target applications most comfortably.

However, since you asked;
Garbage collection,
Multiple inheritance,
Design by Contract (inheritable assertions)
Parametric classes (OK, sort of the same as generics, but more formalised)
A complete inheritance heirachy

>One application I can think of, and which I've had a some experience with,
>is with real-time embedded applications.  I can say that having done it
>both in C and Ada, my  preference is for Ada.
>
my preference would be modula-2, but you'd probably have a hard time
convincing a customer to let you. C might still beat Ada on this one at
this stage because of a broader, cheaper, development tool base. When it
comes to hard real time, Assembler is still right up there.

>Another application is in safety-critical applications such as railroad
>control and air traffic control, for which Ada is very highly suited.  In
>fact, Ada is the language of choice for such systems.  (Visit the Ada home
>page, <http://www.adahome.com> , for a list of many companies writing Ada
>software for this domain.)
>

The Ada home page is hardly going to say Ada is a crock. Just like the
Eiffel pages aren't going to say Eiffel is. Here's another interesting
URL;

http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html

[snip]
>
>I think the DOD would prefer you use Ada, but the DOD does not mandate
>Ada's use.  As a contractor to the government, you are free to use whatever
>language you feel is most appropriate (in the context of a systems
>engineering analysis).  That there is no mandate for the use of Ada should
>be interpreted to mean that Ada is a strong enough language that it doesn't
>require a mandate.
>
Ada has probably got enough momentum now to keep going without a DOD
mandate. However, now DOD has opened the door...

>Note too that the idea that Ada is "used for military applications only" is
>a myth.  There many safety-critical systems - not military in any way -
>written in Ada.  For example, the Boeing 777 is an all-Ada system.  
>
>What language do you feel is better than Ada for safety-critical systems? 
>Can you explain what features that language has that makes it so?  I would
>like to learn what you know about safety-critical applications.
>
Eiffel is IMHO a better choice for safety-critical applications without
excessive real time requirements. Design by contract obviously (and
measurably?) contributes significantly to program safety. Combining this
with a complete inheritanc heirachy of library classes with all the
contracts defined and inheritable has to make a huge difference.

OO and real time never were good bed-fellows, but they are getting more
comfortable together all the time. However, I would probably still go for
a procedural language becuase most control-systems theory is well
formalised to produce a procedural design.

>Also, I'm not sure what you mean by the comment that Ada is good because it
>means "more money for programmers."  As a consultant, my fee is the same
>for Ada, C, C++, Java, or whatever other language you ask me to use.
>
But I bet you get more Ada work because there is currently more demand for
Ada programmers per available programmer than for the other languages.

A good URL on languages and language comparisons is;

http://www.progsoc.uts.edu.au/~geldridg/cpp/

ABO

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

[Jon S Anthony]

In article <slrn5rq1gc.che.abo@minkirri.apana.org.au> abo@minkirri.apana.org.au (Donovan Baarda) writes:

> >Also, at least a couple of other compiler vendors in the real-time market
> >have purchased Intermetric's Ada-Magic front end, so that they too can
> >spend their time on optimization, because they were able to buy the front
> >end off the shelf.
> >
> what this also means is the front end is non-trivial, and they were better
> off paying someone else a fortune for it than developing their own.

What this _really_ means is that a) finally someone somewhere produced
a truely reusable _and_ non-trivial "component" and b) finally some
others have woke up to the fact that "rolling your own" really sucks.


> >So again, I am confused by the comment that "compiler writers don't have
> >time to optimize the code," because there is ample evidence to the
> >contrary.  For which compiler writers specifically is this the case?
> >
> What I should have said is; given equivalent time and resources, people
> developing compilers for simpler languages will be able to put more work
> into optimization than people developing Ada.

First, define "simpler".  On an obvious level Lisp is _vastly_ simpler
than C.  But doing a truely good implementation is a lot harder.
Second, I don't see the relevance.  The end result is what counts.
Given equal time and resources people building bicycles will be able
to optimize the hell out of them over the same level achieved for an
ICE.  So what?  This sort of mentality is the absolute _bane_ of
software.  The reason why it can't seem to build upon itself in any
way.  And the reason why most of it sucks.


> My original point was that arguing for your-gol based on language
> merits alone is asking for trouble, because sure as chips there's
> going to be some-gol out there that does it better.

"In a particular area or context", is the very important bit you left
out.  Of course, when this bit is added in, your point is not exactly
interesting.


> Particularly with a language as old as Ada. I know Ada 95 is more
> recent, but bolting OO onto a procedural language is always a
> compromise compared to starting with a clean slate.

Depends on.  In the case of Ada95, this was not much of a "compromise"
as it was simply extending a couple bits of what was already in Ada83.
What many people (for some reason) don't seem to realize is that Ada83
had the concept of "class", had inheritance and allowed for the
extension of _behavior_ in type derivations.  Adding in dynamic
binding and state extension was pretty natural.


> Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
> does in 40 reserved words and 81 syntax rules. The only things missing
> from modula-2 that are in Ada are generics, exceptions, and operator
> overloading.

And tasking and unconstrained types and ...  This is pretty silly.
No, it's _very_ silly.


> However, it makes up for these deficiencys by having late binding
> (through procedure variables) and a neater, cleaner, simpler syntax.

Not particularly.


> Europe, and has been an inspiration for many other languages
> since. Most languages that claim inheritance from Ada usualy owe
> more to Modula-2.

Neither is particularly innovative.  In fact, no computer language
really is.  But, the things in Ada that were "important" in "proof for
everyday useage" were not in M2: Tasking, Generics, Exceptions, and
(possibly) overloading.


> However, since you asked;
> Garbage collection,

Agreed (though it is recommended by the standard)

> Multiple inheritance,

Strongly disagree.  Actually, far more useful and expressive would be
multiple dispatch (but that is certainly a whole other kettle of
fish).

> Design by Contract (inheritable assertions)

More like class invariants.

> A complete inheritance heirachy

Presumably ala' Eiffel or some such.  Why?  Seems a big shrug.


> The Ada home page is hardly going to say Ada is a crock. Just like the
> Eiffel pages aren't going to say Eiffel is. Here's another interesting
> URL;
> 
> http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html

No, this is not an interesting URL.  Unless you think simplistic
advertising passed off as "objectivity" is.  A large, and mostly
non-productive, "discussion" resulted from this, the last time it was
brought up.  Go back and check the results.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

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

[Larry Kilgallen]

Organization: LJK Software
Lines: 26

In article <slrn5rq1gc.che.abo@minkirri.apana.org.au>, abo@minkirri.apana.org.au (Donovan Baarda) writes:
> On Fri, 04 Jul 1997 00:16:15 -0800, Matthew Heaney <mheaney@ni.net> wrote:

>>Also, at least a couple of other compiler vendors in the real-time market
>>have purchased Intermetric's Ada-Magic front end, so that they too can
>>spend their time on optimization, because they were able to buy the front
>>end off the shelf.
>>
> what this also means is the front end is non-trivial, and they were better
> off paying someone else a fortune for it than developing their own.

I, for one, would not equate "trivial" with "good".

At least one of the companies which paid "a fortune" managed to
price the resultant compiler low enough that I can afford it, so
what their total cost was does not concern me (since I have no
intention of getting into the compiler business :-).

Buying from someone else rather than "developing their own"
is what one would call "re-use".  I thought software "re-use"
was one of the _favored_ buzz-words this year.  Of course whether
"re-use" is good or not certainly depends on the quality of the
code which is being re-used.  Presumably those who paid "a fortune"
evaluated the quality of the code before they opened their wallet.

Larry Kilgallen

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

[John Nagle]

abo@minkirri.apana.org.au (Donovan Baarda) writes:
>the book I've got says that programs that depend on the mechanism used are
>erroneous. I would take a bloody good compiler to raise an error on a
>program that does it.

    It can be done.  See my "Practical Program Verification", 
POPL '83.

>>>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. 

    C++, though, is now bigger than Ada.

>>I think the DOD would prefer you use Ada, but the DOD does not mandate
>>Ada's use.

    At one time DOD did mandate Ada, but they gave up.

						John Nagle

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

[Donovan Baarda]

In article <JSA.97Jul4200941@alexandria.organon.com>, you wrote:
>
>> Particularly with a language as old as Ada. I know Ada 95 is more
>> recent, but bolting OO onto a procedural language is always a
>> compromise compared to starting with a clean slate.
>
>Depends on.  In the case of Ada95, this was not much of a "compromise"
>as it was simply extending a couple bits of what was already in Ada83.
>What many people (for some reason) don't seem to realize is that Ada83
>had the concept of "class", had inheritance and allowed for the
>extension of _behavior_ in type derivations.  Adding in dynamic
>binding and state extension was pretty natural.
>

Can you inherit from an INTEGER? Subtyping is not the same thing. Is there
a parent class to INTEGER and FLOAT that can be used by a class that
manipulates either?

>
>> Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
>> does in 40 reserved words and 81 syntax rules. The only things missing
>> from modula-2 that are in Ada are generics, exceptions, and operator
>> overloading.
>
>And tasking and unconstrained types and ...  This is pretty silly.
>No, it's _very_ silly.
>
Modula-2 had tasking. I'm not exactly sure what you mean by unconstrained
types, but if you mean unconstrained array types, modula-2 didn't have
them exactly but it did have unconstrained array parameters. However, I do
belive that being able to make a type out of them is a neat idea.

>
>Neither is particularly innovative.  In fact, no computer language
>really is.  But, the things in Ada that were "important" in "proof for
>everyday useage" were not in M2: Tasking, Generics, Exceptions, and
>(possibly) overloading.
>
Generics and Exceptions were a pretty important step. However, I don't
believe they were fully understood at the time Ada83 was implemented, and
there are now nicer implementations of these two concepts.

>> A complete inheritance heirachy
>
>Presumably ala' Eiffel or some such.  Why?  Seems a big shrug.
>
It makes a difference in OO because you can make something that
manipulates OBJECTs, and know that it can be fed anything because
everything is inherited from OBJECT. A complete heirachy of numeric types
is useful for the same reason.

ABO

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

[Donovan Baarda]

On Fri, 4 Jul 1997 15:11:35 -0700, Brian Rogoff <bpr@shellx.best.com> wrote:
>On 4 Jul 1997, Donovan Baarda wrote:
>> On Fri, 04 Jul 1997 00:16:15 -0800, Matthew Heaney <mheaney@ni.net> wrote:
[snip]
>No, the gcc backend is (was?) C specific, and other languages like Fortran
>77 also require changes (in particular to handle aliased arrays). The
>changes that make it into gcc are those which can do the greatest good for
>the greatest number of languages.
>
As a matter of interest, were the extensions added to the gcc backend for
Ada and Fortran merged and added to the gcc back end in general, or are
they mantained seperately as language specific backends?

>> The gcc back end already has pretty impressive optimisation.
>
>I wonder how g77 users regard the level of optimization compared to 
>a good Fortran compiler?
>
Me too.

>I agree that Ada sucks, but I think all current computer languages suck in 
>one way or another. Language choice is a minimization-of-suckfullness
>problem with lots of variables. I think Ada 95 is reasonable solution for 
>some problems for now. 
>
Agreed :-) 
I also believe in using the best tool for the job, which means choosing
the best language for the application. It is easy to fall into the trap
of thinking that all you need is one language. Perhaps the root of all my
complaints about Ada stem from the fact that it tried to be the one tool
for everything.

>The only things missing are GENERICS, EXCEPTIONS, and operator overloading?
>Sorry, no generics makes a statically typed language lame. I can do without 
>language minimalism myself. In fact I even wish Ada had user defined
>operators like Algol 68! I agree that Ada would be better with Pascal style 
>procedure parameters, but you can fake them with generics or (to be
>compiler-specific) with Unrestricted_Access in GNAT.
>
Procedure variables in a staticly typed language with no generics make it
less lame. However, generics are a neat feature. When I need them in
modula-2 I use the M4 macro-pre-processor to implement them (A trick I
learned at Uni that was being used with Pascal by one lecturer).

>> Feature counting alone is not enough to gauge the technical merits. Too
>> many features can also compromise a language. The thing to aim for is the
>> minimum number of features required to cover the maximum number of
>> target applications most comfortably.
>
>Its still not a well-posed problem, and intelligent people will disagree 
>on what is "good". Lots of people think that OO is mostly BS and would 
>prefer languages based on genericity, higher order functions, and such. 
>
I never said it was easy. Mostly it is very subjective, which is the main
reason why language flame wars are a waste of time. (Says I, who started
this one :-)

>The rest of this is an ad for Eiffel, which Donovan seems to like, but 
>which, IMHO, also sucks.
>
Actualy, it does look a bit like an ad for Eiffel, but I didn't mean it
quite that way. Eiffel also has its limitations, and is definitely not for
every application. However, IMHO, in most of the applications that people
advocate Ada for, Eiffel probably would be better. That's if you only take
into account language features, of course.

>-- Brian
>
>PS : Before the Eiffel jihad returns fire, I'll add that Eiffel does
>     not suck nearly as much as many popular languages :-) 
>     
Eiffel's biggest problem is it is even bigger than Ada. It also tries to
be the one tool for everything.

ABO

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

[Brian Rogoff]

On 7 Jul 1997, Donovan Baarda wrote:
> On Fri, 4 Jul 1997 15:11:35 -0700, Brian Rogoff <bpr@shellx.best.com> wrote:
> >No, the gcc backend is (was?) C specific, and other languages like Fortran
> >77 also require changes (in particular to handle aliased arrays). The
> >changes that make it into gcc are those which can do the greatest good for
> >the greatest number of languages.
> >
> As a matter of interest, were the extensions added to the gcc backend for
> Ada and Fortran merged and added to the gcc back end in general, or are
> they mantained seperately as language specific backends?

To the best of my knowledge, someone somewhere (MIT?) is modifying gcc/g77 
to handle Fortran better. Since Ada is very proper about who can point to 
what (aliased variables must be made explicit) the same optimizations will 
be applicable, while C and C++ require some sort of no-alias pragma for 
this.

> I also believe in using the best tool for the job, which means choosing
> the best language for the application. It is easy to fall into the trap
> of thinking that all you need is one language. Perhaps the root of all my
> complaints about Ada stem from the fact that it tried to be the one tool
> for everything.

I never thought of it this way. Coming from a scientific computing 
background, I'd say it is competing with C, C++, Fortran, and Eiffel but
not Matlab, Mathematica, Maple, or Macsyma (or Perl, or Icon, ...).

-- Brian

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

[Martin Tom Brown]

In article <33c2aa99.20716474@news.visi.net>
           cbass@visi.net.no_spam "Canada Bass" writes:

> On 7 Jul 1997 05:07:43 GMT, abo@minkirri.apana.org.au (Donovan Baarda)
> wrote:
> 
> snip:
> >>
> >>> Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
> >>> does in 40 reserved words and 81 syntax rules. The only things missing
> >>> from modula-2 that are in Ada are generics, exceptions, and operator
> >>> overloading.
> >>
> >>And tasking and unconstrained types and ...  This is pretty silly.
> >>No, it's _very_ silly.
> >>
> >Modula-2 had tasking. I'm not exactly sure what you mean by unconstrained
> >types, but if you mean unconstrained array types, modula-2 didn't have
> >them exactly but it did have unconstrained array parameters. However, I do
> >belive that being able to make a type out of them is a neat idea.
> >
> snip:
> 
> I am unsure as to effect of this post, but does M2 have true
> multi-tasking to which he was referring to? I know little of any other
> language that has a standard multi-tasking function. :)

The Modula 2 language standard PIM3 and above contains facilities for 
synchronisation by SIGNAL, cooperative multitasking by TRANSFER and 
interrupt handlers by IOTRANSFER. Modules can also have priority masks.
It is relatively easy to write a timeslice based scheduler in M2 and 
most of the compiler vendors source library files include one.

There is a newly published ISO standard with a complete formal language
specification for Modula2 now, with standardised libraries. Too late :(
It is a neat little language which still holds certain safety critical 
market niches in embedded instrument control and the like.

I still think it is an excellent minimallist language.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

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

[Richard Kenner]

In article <slrn5s1132.hf1.abo@minkirri.apana.org.au> abo@minkirri.apana.org.au (Donovan Baarda) writes:
>As a matter of interest, were the extensions added to the gcc backend for
>Ada and Fortran merged and added to the gcc back end in general, or are
>they mantained seperately as language specific backends?

The changes to GCC for Ada were quite small and were put into the general
GCC distribution quite a long time ago.

There have not been any changes (aside from bug fixes) required for
Fortran.  There are some bouncing around, but they haven't yet reached
the level of being officially suggested for inclusion in GCC.

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

[Joachim Durchholz]

Donovan Baarda wrote:

> >PS : Before the Eiffel jihad returns fire, I'll add that Eiffel does
> >     not suck nearly as much as many popular languages :-)

Good :))

> Eiffel's biggest problem is it is even bigger than Ada.

This sounds strange to me. I feel Ada is more complicated than Eiffel.
And that's comparing the very first draft of Ada with current versions
of Eiffel!
Of course these are just feelings, and from a developer's viewpoint,
too. Under the hood, Eiffel may have more (and more complicated)
features than Ada. But the language design is so clear and
straightforward that most complexity doesn't show until you really want
to know about it.

> It also tries to
> be the one tool for everything.

Not really. It is intended for large systems, where correctness and
clear structure become really important. It is adequate for
intermediate-sized projects. It is not intended for real-time embedded
systems (though one could cramp Eiffel into that environment if one
really wanted to, but then you can do that with C++ or Lisp, too).

Besides, there's nothing wrong in trying to be the one tool for (mostly)
everything. One of the more important cost factor is retraining
programmers for new languages, new paradigms, new libraries, and new
tools. A language must try to be all things to everybody to have a
chance today.
This universality must not make the language bulky, of course. Your
perception of Eiffel's bulkiness may differ, of course, but I find the
language's unbulkiness striking.
Eiffel is even more universal than one might think. It is not just a
programming language, it is also useful for formal specifications in
analysis and design. (One OOAD method actually exploits this. It is BON,
by Kim Wald=E9n and Jean-Marc Nerson.)

Regards,
Joachim

[C and C++ discussion groups clipped.]
-- =

Please don't send unsolicited ads.

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

[Canada Bass]

On 7 Jul 1997 05:07:43 GMT, abo@minkirri.apana.org.au (Donovan Baarda)
wrote:

snip:
>>
>>> Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2
>>> does in 40 reserved words and 81 syntax rules. The only things missing
>>> from modula-2 that are in Ada are generics, exceptions, and operator
>>> overloading.
>>
>>And tasking and unconstrained types and ...  This is pretty silly.
>>No, it's _very_ silly.
>>
>Modula-2 had tasking. I'm not exactly sure what you mean by unconstrained
>types, but if you mean unconstrained array types, modula-2 didn't have
>them exactly but it did have unconstrained array parameters. However, I do
>belive that being able to make a type out of them is a neat idea.
>
snip:

I am unsure as to effect of this post, but does M2 have true
multi-tasking to which he was referring to? I know little of any other
language that has a standard multi-tasking function. :)

Canada Bass

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

[Dale Pontius]

In article <mheaney-ya023680000207972142310001@news.ni.net>,
        mheaney@ni.net (Matthew Heaney) writes:
>
> It is my understanding that because of Cs aggressive use of type-casting,
> optimizations are actually more difficult to make than in Ada, where more
> semantic information is given to the compiler (because of the richness of
> its type system), thus allowing better optimization than is possible for C.
>
But I have this annoying feeling that the programming community is
accustomed to optimizing C, even if it is difficult. Even though
Ada gives more information to the compiler that can be used to
optimize code, I have a feeling compiler writers aren't used to
using that information, and don't. (or at least not much.)

Fortunately, Java may help this situation. In terms of optimization
Java is closer to Ada than C, and there is tremendous pressure to
improve Java performance. As compiler technology develops to optimize
Java, it will be applicable to Ada as well.

Yep, Ada was here sooner. But it doesn't command the market attention
that C, C++, and Java do. So strong-typing-assisted optimization may
be late, but at least it's coming.

Dale Pontius
(NOT speaking for IBM)

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

[Dale Pontius]

In article <33c2aa99.20716474@news.visi.net>,
        cbass@visi.net.no_spam (Canada Bass) writes:
>
> I am unsure as to effect of this post, but does M2 have true
> multi-tasking to which he was referring to? I know little of any other
> language that has a standard multi-tasking function. :)
>
Modula2 has a fundamental capability of executing coroutines. It
has the ability to switch between coroutines, and to enter a
coroutine through an interrupt. The interrupt response routine
also understands interrupt masks. This is pretty much the minimal
set of primitives to implement multitasking

Dale Pontius
(NOT speaking for IBM)

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

[Tucker Taft]

Don Harrison (donh@syd.csa.com.au) wrote:

: Donovan Baarda wrote:

: :Eiffel is IMHO a better choice for safety-critical applications without
: :excessive real time requirements. Design by contract obviously (and
: :measurably?) contributes significantly to program safety. Combining this
: :with a complete inheritanc heirachy of library classes with all the
: :contracts defined and inheritable has to make a huge difference.

: I agree on all points. ...

I'm curious what you mean by safety-critical.

In my experience with safety-critical applications, you 
cannot have any significant amount of out-of-line run-time
support, and little or no use of dynamic storage allocation after 
system startup.

Eiffel's dependence on dynamic storage allocation and garbage 
collection basically rules it out for most (serious) safety-critical
applications, despite all its admittedly nice invariants and assertions.

One of the important features of Ada in the safety-critical domain
is that there is a very useful subset that makes little or no use 
of out-of-line run-time support, and essentially no use of dynamic
storage allocation.   Furthermore, there are FAA-certified versions 
of the minimal run-time support required.  I doubt the FAA will
ever certify a garbage collector.

Finally there are available tools (such as the "SPARK" tools from Praxis, 
Ltd.) which add support for all of the kinds of assertions that
Eiffel has, including full static analysis and theorem
proving support of the assertions, while allowing the programmer
to code within a subset of Ada that requires essentially
no out-of-line run-time support, and can still be compiled by any
commercial Ada compiler.

These are some of the reasons why Ada is the language of choice in many
applications that are safety-critical.  It is relatively straightforward
to add additional assertion-checking via pragmas and static analysis tools.  
It is not so easy to take a language like Eiffel that is fundamentally 
oriented toward dynamic storage allocation (and pervasive dynamic binding), 
and adapt it to work in the fully statically analyzable environment required 
for applications where human life is at stake.  

Ada95 was designed to be able to support programming in a way
that minimizes dynamic storage allocation, unnecessary dynamic binding, etc.
while still supporting the object-oriented paradigm and a very strong
and separately compilable contract between the clients 
and the implementation(s) of an abstract interface.  The "contract"
enforced at compile-time by the Ada compiler is much stronger than
the contract enforced at compile-time by most compilers, since it
includes strong type distinctions between otherwise equivalent scalar,
array, and pointer types, plus compiler-enforced parameter modes,
and the ability to use formal parameter names to verify actual/formal
parameter association.

: Don.
: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
: Don Harrison             donh@syd.csa.com.au

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

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

[Matthew Heaney]

In article <slrn5s0ucv.fpc.abo@minkirri.apana.org.au>,
abo@minkirri.apana.org.au (Donovan Baarda) wrote:

>Can you inherit from an INTEGER? Subtyping is not the same thing. Is there
>a parent class to INTEGER and FLOAT that can be used by a class that
>manipulates either?

Wegner described contrasted "subtypes" and "subclasses."

A subtype has range semantics, in the sense that a subtype constrains the
range of values that may be designated by an object.

A subclass has template semantics, in the sense that a subclass constrains
the behavior of its parent.

But you can think of an object of a subclass as only being able to
designate fewer values, because it has more behavior constraints.

Ada has both specialization mechanisms.  However, "type extension" is not
available for numeric types such as Integer or Float, only subtype (range)
constraints.  So, numeric types such as Integer or Float are not related in
any kind of inheritence hierarchy (ie don't have a common superclass).

Different languages have made different choices with respect to whether all
types should be part of a common hierarchy.  That Eiffel did so, and Ada
did not, should not be construed as better, just different.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

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

[Don Harrison]

Donovan Baarda wrote:

:Actualy, it does look a bit like an ad for Eiffel, but I didn't mean it
:quite that way.

That's okay - it deserves your praise.  :)

:Eiffel's biggest problem is it is even bigger than Ada. 

Not sure what you mean here. If you mean that it's complex, I would have to
disagree. In fact, as a minimalist language, it's very small and simple. Great
care has been taken in Eiffel's design to provide the minimal required 
mechanisms in the core language and to deliver advanced functionality through 
reuse, that is via libraries. This is the exact antithesis of Ada which is 
maximalist and complex. The Ada solution to adding functionality is adding 
(yet another) language feature. Consequently, Ada is about an order of magnitude
more complex than Eiffel due to the myriad interactions of language features.

According to Bertand Meyer, the explosion of language features in Ada-9X even
led to the resignation of Jean Ichbiah (one of Ada's original designers):

  "It is interesting to note that Jean Ichbiah, the creator of Ada, resigned
   publicly from the Ada95 reviewing group after trying in vain for several
   years to keep the extensions simple. His long resignation letter includes 
   comments such as: 'A massive increase in complexity will result from 9X
   [later renamed Ada95] adding one or more additional possibilities where 
   Ada now offers two. For example, 9X adds: [...] access parameters, to in, 
   out and in out; tagged types, to normal types, dipatched subprogram calls,
   to normal subprogram calls; use type clause to use package clauses; [Other
   examples skipped; overall 12 were included.] With 9X, the number of 
   interactions to consider is close to 60,000 since we have 3 or more 
   possibilities in each case (that is, 3**10).' "

[Source: Object-Oriented Software Construction 2nd ed.]
 
:It also tries to
:be the one tool for everything.

Being general purpose is fine, IMO.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

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

[Don Harrison]

Donovan Baarda wrote:

:Eiffel is IMHO a better choice for safety-critical applications without
:excessive real time requirements. Design by contract obviously (and
:measurably?) contributes significantly to program safety. Combining this
:with a complete inheritanc heirachy of library classes with all the
:contracts defined and inheritable has to make a huge difference.

I agree on all points.

Realtime development will be an interesting one for Eiffel if the SCOOP 
concurrency model is adopted. IMO, Eiffel will offer a better alternative
to Ada, probably even for hard realtime systems. This is because SCOOP:

  1) Allows safe sharing of data, 
  2) Allows easy reallocation of threads to different processors, and
  3) Integrates concurrency with the class and contracting models.

WRT 1), SCOOP provides automatic locking of shared data so that users don't 
have to worry about it. Adding protected types to Ada to protect shared data
is a good idea, but if you use tasks on their own you have to roll-your-own
data protection using semaphores, for example, which is error prone.

While you can choose to do the right thing for new systems, your software will
be more reliable if the language takes care of locking automatically. Also (as 
Robert Dewar is fond of reminding us), you're not always in a position to 
choose - for example when using legacy code.

WRT 2), SCOOP allows you to reconfigure your system by re-allocating threads
to different processors to optimise performance without changing any code.
This is done in an external Concurrency Configuration File. This would be 
particularly valuable for realtime systems because you could logically partition 
the system according to how hard the realtime constraints are and allocate the 
hard bits to dedicated processors. Such partitioning would also allow liberal use
of assertions in the softer parts of the system where performance is not 
critical.

Some Ada implementations probably allow such flexibility as well but it 
certainly couldn't be any simpler than in SCOOP.

WRT 3), by integrating concurrency with classes and contracting, SCOOP offers 
a simpler (just classes - not tasks + protected types), more flexible (objects 
are not constrained to being either active or passive; concurrent classes may 
be extended through inheritance) and more powerful (synchronisation and 
correctness may be inherited) model than Ada's.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

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

[Nick Leaton]

Matthew Heaney wrote:

> Different languages have made different choices with respect to whether all
> types should be part of a common hierarchy.  That Eiffel did so, and Ada
> did not, should not be construed as better, just different.

I'm not sure about this. If you don't have a common hierarchy, then that
precludes you from using a common root. Now this is useful when we look
at container classes. It is particularly useful when you can constrain
the type that is store in a container to a particular type. 

By having a common hierarchy you are not limited from doing anything
that you can without one. However the reverse is not true. Therefore a
common heirarchy is the better solution.

-- 

Nick

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

[Matthew Heaney]

In article <33C4AF0E.339D@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> wrote:

>> Different languages have made different choices with respect to whether all
>> types should be part of a common hierarchy.  That Eiffel did so, and Ada
>> did not, should not be construed as better, just different.
>
>I'm not sure about this. If you don't have a common hierarchy, then that
>precludes you from using a common root. Now this is useful when we look
>at container classes. It is particularly useful when you can constrain
>the type that is store in a container to a particular type. 

I think there is confusion here between what one does versus how one does it.

In Ada, you can constrain the type you use to parameterize a container
class, it's just that the mechanism for doing so is different from Eiffel.

For example, I can parameterize a type with any assignable type:

generic
   type T is private;
package Containers_G is

   type Root_Container is abstract tagged private;
...

I can constrain the generic formal type so that it only allows integers:

generic
   type T is range <>;
package Containers_G is ...;

I can constrain the type to only integer types that derive from integer
type T (example *):

generic
   type NT is new T;
package Containers_G is ...;

I can constrain the type to any type with an addition operator:

generic
   type T is private;
   with function "+" (L, R : T) return T is <>;
package Containers_G is ...;

I can constrain the type so that it only takes tagged types (those that
have type extension):

generic
   type T is tagged private;
package Containers_G is ...;

I can constrain the type so that it only takes tagged types that derive
from a specific tagged type T (example **):

generic 
   type NT is new T with private;
package Containers_G is ...;

Examples (*) and (**) are examples of "constrained genericity," which is
exactly what you said would be really nice to have.  So you have it an
Eiffel AND Ada.

So what's the problem?   In Ada, you can constrain the type used to
parameterize another, without all types necessarily being related via a
hierarchy.  That Eiffel does it differently from Ada should be construed
only to mean that Eiffel does it differently from Ada, not better.

In Ada, you can even do mixin inheritance without using multiple
inheritance.  Imagine that!

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

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

[Nick Leaton]

Matthew Heaney wrote:


> In Ada, you can even do mixin inheritance without using multiple
> inheritance.  Imagine that!

And you can use MI for it in Eiffel, without the problems of C++!

-- 

Nick

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

[Don Harrison]

Matthew Heaney wrote:

:In article <33C4AF0E.339D@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> wrote:
:
:>> Different languages have made different choices with respect to whether all
:>> types should be part of a common hierarchy.  That Eiffel did so, and Ada
:>> did not, should not be construed as better, just different.
:>
:>I'm not sure about this. If you don't have a common hierarchy, then that
:>precludes you from using a common root. Now this is useful when we look
:>at container classes. It is particularly useful when you can constrain
:>the type that is store in a container to a particular type. 
:
:I think there is confusion here between what one does versus how one does it.

I think what Nick means is that because Ada does not define Integer and Float 
as classes inheriting from a common ancestor class Numeric, they are less 
flexible than in Eiffel. In particular, you can't declare a generic Numeric 
container class and constrain *through inheritance* to store Integers or Floats. 
Consequently, you can't use a Numeric container polymorphically by substituting
an Integer or Float container. Also, you can't store both Floats and Integers 
in the same Numeric container. These things are simple and straightforward 
to do in Eiffel because INTEGER and REAL are both classes (as well as types)
inheriting from class NUMERIC. 

In Ada, there is something like a notional Numeric *type* having properties
like assignment and addition but because it is not a class (tagged type), it's
not extensible through inheritance. You may be able to extend using Ada's
*other* inheritance mechanism - derived types - but that doesn't allow 
polymorphism so you miss something compared with Eiffel.


:In Ada, you can constrain the type you use to parameterize a container
:class, it's just that the mechanism for doing so is different from Eiffel.

[examples of constrained numeric types unrelated by inheritance]

:I can constrain the type so that it only takes tagged types (those that
:have type extension):

[example of constrained *non-numeric* type related by inheritance]

:Examples (*) and (**) are examples of "constrained genericity," which is
:exactly what you said would be really nice to have.  So you have it an
:Eiffel AND Ada.

No, I think Nick meant constraining from a common ancestor *through 
inheritance* which is different from the examples you have given. We already 
know that both Ada and Eiffel support both constrained and unconstrained
genericity.

:In Ada, you can even do mixin inheritance without using multiple
:inheritance.  

Yes, through a round-about way using genericity. This is inelegant compared 
with multiple inheritance. However, it's simple compared to the obscure 
technique for acheiving multiple views in Ada95 Rationale, Section 4.6.3.
I'm still trying to comprehend that one!
 
:Imagine that!

Imagine!


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

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

[Jon S Anthony]

In article <EDAsu7.MLn@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> I think what Nick means is that because Ada does not define Integer
> and Float as classes inheriting from a common ancestor class
> Numeric, they are less

Who cares.  In typical practice this is not even going to be used -
the efficiency sucks for any real numerical work and you will have to
resort to expanded types anyway.


> flexible than in Eiffel. In particular, you can't declare a generic
> Numeric container class and constrain *through inheritance* to store
> Integers or Floats.  Consequently, you can't use a Numeric container
> polymorphically by substituting an Integer or Float container. Also,
> you can't store both Floats and Integers in the same Numeric
> container. These things are simple and straightforward to do in
> Eiffel because INTEGER and REAL are both classes (as well as types)
> inheriting from class NUMERIC.

Shrug.  If you want that, just build Numeric.  But really, I doubt
that this is something you will want in the sort of applications Ada
and Eiffel target.  You want this sort of stuff?  Use CL.


> In Ada, there is something like a notional Numeric *type* having
> properties like assignment and addition but because it is not a
> class (tagged type), it's not extensible through inheritance. You

False.  You can extend and change the _behavior_ through inheritance.


> *other* inheritance mechanism - derived types - but that doesn't allow 
> polymorphism so you miss something compared with Eiffel.

Right.  As for polymorphism here - again who cares? as it is not very
likely that you want dispatching on individual numbers anyway.


> :Examples (*) and (**) are examples of "constrained genericity," which is
> :exactly what you said would be really nice to have.  So you have it an
> :Eiffel AND Ada.
> 
> No, I think Nick meant constraining from a common ancestor *through 
> inheritance*

OK, but again - who cares?  IMO, forcing everything into a
classification style of model naive, simplistic, overly constraining,
and typically wrong.


> :In Ada, you can even do mixin inheritance without using multiple
> :inheritance.  
> 
> Yes, through a round-about way using genericity. This is inelegant compared 
> with multiple inheritance.

No it is not.  IMO, for mixins, the generic + SI is a _much_ better
model as it does not confuse the issue with any sort of is-a
semantics.  Just because I want to mixin a printing capability with my
rational number facility, does not mean that my rational numbers
suddenly become printers, but with MI, that is basically what you are
saying even though you probably don't mean it.  What you are really
looking for with mixins is composition with a form of automatic
delegation.


> However, it's simple compared to the obscure technique for acheiving
> multiple views in Ada95 Rationale, Section 4.6.3.  I'm still trying
> to comprehend that one!

It is obscure, but not particularly difficult.  However, I agree that
is the one case where MI is actually useful.  OTOH, this is relatively
rare thing.  IMO, if you really want/need this level of capability,
then you may as well just use CLOS, as it is far more capable than
either Ada's or Eiffel's object model.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

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

[Matthew Heaney]

In article <EDAsu7.MLn@syd.csa.com.au>, donh@syd.csa.com.au wrote:

>Yes, through a round-about way using genericity. This is inelegant compared 
>with multiple inheritance. However, it's simple compared to the obscure 
>technique for acheiving multiple views in Ada95 Rationale, Section 4.6.3.
>I'm still trying to comprehend that one!

Be careful bandying about terms like "more elegant" and "less pure."  Those
are concepts invented by humans to convey an idea to another human.  Nature
doesn't care about what is more or less elegant, she only cares about what
works and what doesn't.

As system builders, especially as builders of software systems, we always
have to be concerned with keeping things simple.  The language designer
must balance expressiveness of the language against inclusion of yet more
features.

Does the putative "elegance" of the MI solution outweigh the language
complexity that would result had MI been included in Ada?  Doesn't
simplicity count for something?  Should one reject Ada out of hand, because
mixin inheritance in Ada using generics is "inelegant" compared to using
multiple inheritence in Eiffel?

Isn't it possible that there are other features of Ada, that allow some
things to be done more easily or more elegantly than in Eiffel?  Is the
mechanism used to implement mixin inheritance so important that those other
features aren't significant?

The multiple view technique is an admittedly difficult idiom to understand
- at first.  But once apprehended, it makes perfect sense, and isn't hard
to do.  You get multiple views for free, because it builds on existing
language mechanisms, and it very nearly gives you what you get in MI,
without requiring that MI be part of the language.

You may want to study my discussion of the Adapter pattern in the SIGAda
patterns WG archives, where I specifically discuss and give code examples
of the multiple views technique.

<http://www.acm.org/sigada>

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

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

[Don Harrison]

Jon S Anthony wrote:

:In article <EDAsu7.MLn@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
:
:> I think what Nick means is that because Ada does not define Integer
:> and Float as classes inheriting from a common ancestor class
:> Numeric, they are less
:
:Who cares.  In typical practice this is not even going to be used -
:the efficiency sucks for any real numerical work and you will have to
:resort to expanded types anyway.

The convenience is there if you need it. You don't even have that option in Ada.


:> flexible than in Eiffel. In particular, you can't declare a generic
:> Numeric container class and constrain *through inheritance* to store
:> Integers or Floats.  Consequently, you can't use a Numeric container
:> polymorphically by substituting an Integer or Float container. Also,
:> you can't store both Floats and Integers in the same Numeric
:> container. These things are simple and straightforward to do in
:> Eiffel because INTEGER and REAL are both classes (as well as types)
:> inheriting from class NUMERIC.
:
:Shrug.  If you want that, just build Numeric.  But really, I doubt
:that this is something you will want in the sort of applications Ada
:and Eiffel target.  

Ditto.


:> In Ada, there is something like a notional Numeric *type* having
:> properties like assignment and addition but because it is not a
:> class (tagged type), it's not extensible through inheritance. You
:
:False.  You can extend and change the _behavior_ through inheritance.

Try reading the whole paragraph instead of quoting out of context - it's obvious
I'm talking about inheritance ala tagged types.

:> *other* inheritance mechanism - derived types - but that doesn't allow 
:> polymorphism so you miss something compared with Eiffel.
:
:Right.  As for polymorphism here - again who cares? as it is not very
:likely that you want dispatching on individual numbers anyway.

Possibly.


:> :Examples (*) and (**) are examples of "constrained genericity," which is
:> :exactly what you said would be really nice to have.  So you have it an
:> :Eiffel AND Ada.
:> 
:> No, I think Nick meant constraining from a common ancestor *through 
:> inheritance*
:
:OK, but again - who cares?  IMO, forcing everything into a
:classification style of model naive, simplistic, overly constraining,
:and typically wrong.

In your opinion.


:> :In Ada, you can even do mixin inheritance without using multiple
:> :inheritance.  
:> 
:> Yes, through a round-about way using genericity. This is inelegant compared 
:> with multiple inheritance.
:
:No it is not.  IMO, for mixins, the generic + SI is a _much_ better
:model as it does not confuse the issue with any sort of is-a
:semantics.  Just because I want to mixin a printing capability with my
:rational number facility, does not mean that my rational numbers
:suddenly become printers, 

Depending on who you listen to, that's an inappropriate use of MI.

:but with MI, that is basically what you are
:saying even though you probably don't mean it.  What you are really
:looking for with mixins is composition with a form of automatic
:delegation.
:
:
:> However, it's simple compared to the obscure technique for acheiving
:> multiple views in Ada95 Rationale, Section 4.6.3.  I'm still trying
:> to comprehend that one!
:
:It is obscure, but not particularly difficult.  However, I agree that
:is the one case where MI is actually useful.  OTOH, this is relatively
:rare thing.  IMO, if you really want/need this level of capability,
:then you may as well just use CLOS, as it is far more capable than
:either Ada's or Eiffel's object model.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

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

[Jon S Anthony]

In article <EDCJ0J.JKI@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Jon S Anthony wrote:
> 
> :In article <EDAsu7.MLn@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
> :
> :> I think what Nick means is that because Ada does not define Integer
> :> and Float as classes inheriting from a common ancestor class
> :> Numeric, they are less
> :
> :Who cares.  In typical practice this is not even going to be used -
> :the efficiency sucks for any real numerical work and you will have to
> :resort to expanded types anyway.
> 

> The convenience is there if you need it. You don't even have that
> option in Ada.

??? Of course you do.  That's what I meant by building a "Numeric"
tagged type (speaking of reading/quoting things in overall
context...).  Of course, you do actually have to build it if you
really want this and _that_ might be considered a disadvantage.


> :Shrug.  If you want that, just build Numeric.  But really, I doubt
> :that this is something you will want in the sort of applications Ada
> :and Eiffel target.  
> 
> Ditto.

Ditto.


> :> :Examples (*) and (**) are examples of "constrained genericity," which is
> :> :exactly what you said would be really nice to have.  So you have it an
> :> :Eiffel AND Ada.
> :> 
> :> No, I think Nick meant constraining from a common ancestor *through 
> :> inheritance*
> :
> :OK, but again - who cares?  IMO, forcing everything into a
> :classification style of model naive, simplistic, overly constraining,
> :and typically wrong.
> 
> In your opinion.

Right - as stated.  The important point being that the contrary view
is _just opinion_ as well.  And IMO (:-), not at all convincing.
Especially as there are loads of alternative modeling styles used
everywhere everyday.


> :No it is not.  IMO, for mixins, the generic + SI is a _much_ better
> :model as it does not confuse the issue with any sort of is-a
> :semantics.  Just because I want to mixin a printing capability with my
> :rational number facility, does not mean that my rational numbers
> :suddenly become printers, 
> 
> Depending on who you listen to, that's an inappropriate use of MI.

But _not_ of mixins.  Which is exactly the point.

> 
> :but with MI, that is basically what you are
> :saying even though you probably don't mean it.  What you are really
> :looking for with mixins is composition with a form of automatic
> :delegation.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

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

[Robert I. Eachus]

In article <33C4AF0E.339D@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:

  > Matthew Heaney wrote:

  >> Different languages have made different choices with respect to
  >> whether all types should be part of a common hierarchy.  That
  >> Eiffel did so, and Ada did not, should not be construed as
  >> better, just different.

  > I'm not sure about this. If you don't have a common hierarchy, then that
  > precludes you from using a common root. Now this is useful when we look
  > at container classes. It is particularly useful when you can constrain
  > the type that is store in a container to a particular type. 

  > By having a common hierarchy you are not limited from doing anything
  > that you can without one. However the reverse is not true. Therefore a
  > common heirarchy is the better solution.

     But you should never let consistancy get in the way of doing the
"right" thing.  Ada does have a common hierarchy, but as it says right
under the language-defined class chart at RM 3.2(12), "The classes
'numeric' and 'nonlimited' represent other classification dimensions
and do not if into the above strictly hierarchical picture." RM 3.2(13)

     In Ada integer types are grouped with enumeration types into
discrete types, while floating point types are grouped with ordinary
fixed point types and decimal fixed point types into real types.

     Of course, if you don't like this hierarchy, you can create your
own, and even if you want have all classes rooted at 'Object'.  But
you will lose some of the richness of the Ada organization if you stay
inside such a family of classes.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

[Brian Rogoff]

(C, C++ groups removed...)
On Tue, 15 Jul 1997, Matthew Heaney wrote:
> In article <EDAsu7.MLn@syd.csa.com.au>, donh@syd.csa.com.au wrote:
> >Yes, through a round-about way using genericity. This is inelegant compared 
> >with multiple inheritance. However, it's simple compared to the obscure 
> >technique for acheiving multiple views in Ada95 Rationale, Section 4.6.3.
> >I'm still trying to comprehend that one!
> 
> Be careful bandying about terms like "more elegant" and "less pure."  Those
> are concepts invented by humans to convey an idea to another human.  Nature
> doesn't care about what is more or less elegant, she only cares about what
> works and what doesn't.

Most of us got it the first time: Eiffel way good, Ada way bad. I am
disgusted with myself for preferring Ada 95 to Eiffel, and I must be warped
because I  find the self referential structure of the MI in the Rationale
4.6.3 (http://www.adahome.com/LRM/95/Rationale/rat95html/rat95-p2-4.html#6 for 
those of you who want to see for yourselves) *beautiful*, and worth the 
small effort invested in comprehension.

Interestingly, the creators of BETA also decided to leave out MI as well. 
But I guess they must be poor designers too. There is only one true OOP 
way after all, and Don *knows* it.

And people who use SML must be the most barbarous of all, since they don't 
have "objects"! How can they do anything?

-- Brian

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

[Don Harrison]

Matt Heaney wrote:

:In article <EDAsu7.MLn@syd.csa.com.au>, donh@syd.csa.com.au wrote:
:
:>Yes, through a round-about way using genericity. This is inelegant compared 
:>with multiple inheritance. However, it's simple compared to the obscure 
:>technique for acheiving multiple views in Ada95 Rationale, Section 4.6.3.
:>I'm still trying to comprehend that one!
:
:Be careful bandying about terms like "more elegant" and "less pure."  Those
:are concepts invented by humans to convey an idea to another human.  Nature
:doesn't care about what is more or less elegant, she only cares about what
:works and what doesn't.

Have to disagree here. Appreciation of elegance and purity are God-given
qualities which many either suppress or don't have much of in the first place.
Judging by God's handiwork, He possesses them in abundance. 

IMO, it's software users that don't care about elegance and purity but only 
inasmuch as it doesn't affect them. That is, they couldn't care less if 
software is inelegant under-the-covers so long as it works and is easy to use. 
Unfortunately, what's more likely is that it won't work and won't be easy to 
use if it's design is complex - a poor designer doesn't radically change the 
way they do things when they come to the GUI and complexity tends to compromise
reliability. 

:As system builders, especially as builders of software systems, we always
:have to be concerned with keeping things simple.  

I agree.

:The language designer
:must balance expressiveness of the language against inclusion of yet more
:features.

I tend to think there are good and bad ways of delivering functionality -
see below... 


:Does the putative "elegance" of the MI solution outweigh the language
:complexity that would result had MI been included in Ada?  Doesn't
:simplicity count for something?  

Yes, it counts for a lot. However, I think it's helpful to recognise the 
relative complexity engendered by the two primary means of delivering 
functionality - language mechanisms and libraries. The former increases 
overall complexity more than the latter because language features interact 
with each other *non-orthogonality* and libraries are *standalone*. Also, I 
think we need to distinguish between *actual* and *perceived* orthogonality. 
A naive user, for example, may perceive a language such as Ada to be more 
complex than it actually is simply because they don't know what is orthogonal 
and what isn't. 

As an example of the standalone complexity of libraries (strictly in Ada it's
optional language and libraries), Ada is not made more complex for a 
realtime user due to the existence of an Information Systems Annexe
because it's immediately obvious from the fact that it's optional that it 
doesn't concern them. The same can't be said of language mechanisms whose 
orthogonality is recognised more through use rather than immediate 
comprehension. Most humans can only grasp a handful of concepts at a time 
so it's asking too much of them to immediately comprehend which of a multitude
of language mechanisms are independent of each other. Obviously, the fewer 
there are, the less there is to learn and the quicker you will master the 
language.

I doubt anyone would disagree that Annexes are a good idea. Minimalist 
languages (such as Eiffel) take this principle further by placing as much 
functionality as possible in "Annexes" (called libraries in Eiffel). In this 
way, the basic functionality of the language is reused heavily to provide 
other functionality. The analogy on the back of "Eiffel The Language" (ETL) 
is very apt:

  "Eiffel has been called a 'RISC language'".

Some examples of this reuse which contrast with Ada are:

  - Implementation of basic types as classes.
  - Implementation of parts of the exception facilities as a class.
  - Implementation of various aspects of concurrency (timed interrupts, 
    coroutines etc.) as classes.

The more functionality you can implement in standalone libraries, the simpler
the language itself becomes. A rough measure of that complexity is language 
validity rules. Eiffel only has about 81 including SCOOP. How many does Ada95 
have? (I mean the number of distinct RM references which an Ada compiler can
spit out) I've roughly estimated about 2400 - I can't tell for sure because the 
Librarian has annexed my copy of the LRM. This difference translates fairly 
directly into how complex the language is perceived to be, especially to a 
beginner.


In the specific case of MI, I think it's such a useful modelling tool as to 
warrant its inclusion in the language itself if that will make it easier to use
(which I think it does).


:Should one reject Ada out of hand, because
:mixin inheritance in Ada using generics is "inelegant" compared to using
:multiple inheritence in Eiffel?

No, but it may mean that you're not able to model things as directly as you 
might otherwise.


:Isn't it possible that there are other features of Ada, that allow some
:things to be done more easily or more elegantly than in Eiffel?  

Sure. Low-level facilities may be one such area. But, IME, it's typically the 
other way round.

:Is the
:mechanism used to implement mixin inheritance so important that those other
:features aren't significant?

I think they're likely to be orthogonal wrt MI.


:The multiple view technique is an admittedly difficult idiom to understand
:- at first.  But once apprehended, it makes perfect sense, and isn't hard
:to do.  You get multiple views for free, because it builds on existing
:language mechanisms, and it very nearly gives you what you get in MI,
:without requiring that MI be part of the language.
:
:You may want to study my discussion of the Adapter pattern in the SIGAda
:patterns WG archives, where I specifically discuss and give code examples
:of the multiple views technique.
:
:<http://www.acm.org/sigada>

Thanks for the reference. If I get a chance, I'll take a look.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

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

[Matthew Heaney]

In article <EDEDB3.8rv@syd.csa.com.au>, donh@syd.csa.com.au wrote:

>:Be careful bandying about terms like "more elegant" and "less pure."  Those
>:are concepts invented by humans to convey an idea to another human.  Nature
>:doesn't care about what is more or less elegant, she only cares about what
>:works and what doesn't.
>
>Have to disagree here. Appreciation of elegance and purity are God-given
>qualities which many either suppress or don't have much of in the first place.
>Judging by God's handiwork, He possesses them in abundance. 

You've fallen into a common trap, Don.  You think that beauty and elegance
exist independent of human perception; this is, of course, incorrect.

Here's a quote for you, to provide an analogy:

"Complexity per se is not the culprit, of course; rather it is our human
limitations in dealing with complexity that cause the problem." - William
Wulf, quoted by Booch

There is no such thing as complexity, really.  Complexity is just a concept
- it's what is felt by a human, when he observes natural phenomena (or the
reaction of this human when he reviews software...).

When you speak of beauty and elegance, those terms have no meaning without
speaking of the human who thinks something is beautiful or the human that
perceives something to be elegant.  A thing is not beautiful all by itself
- it is beautiful only in the mind of a human.

Looking at it from a systems point of view, beauty and elegance are refered
to as "emergent properties," a thing that emerges because of the
interaction of parts.

So we can dispense with any mention of God, because he has nothing to do
with it.  Contrary to they're being handed over by God, "elegance" and
"purity" are simply concepts that emerge because of the structure of the
human brain.  If you take away the human, then of course you take away
elegance and purity to.

You even hint at this yourself, when you say "Judging by God's handiwork." 
It's a _human_ that does the judging; there being no judge, there can be no
elegant handiwork or pure handiwork - just handiwork.

In fact, the concept of God is an emergent property, which emerges as the
result of the interaction of a reflexive system aware of its own mortality,
and a strong, built-in propensity to maintain its own existance ("survival
instinct").  Take away the system, and of course you take away "God" too.

If these concepts are alien to you, then I suggest you study up on systems
thinking.  It'll make you a much better systems designer.  Here's a couple
of books to read

The Blind Watchmaker
Richard Dawkins
W.W.Norton
ISBN 0-393-30448-5

Dealing with Complexity
Robert Flood and Ewart Carson
Plenum Press
ISBN 0-306-44299-X

You may also want to take a gander at Capra's new book

The Web of Life
Fritjof Capra
Anchor Books (Doubleday)
0-385-47675-2


>IMO, it's software users that don't care about elegance and purity but only 
>inasmuch as it doesn't affect them. That is, they couldn't care less if 
>software is inelegant under-the-covers so long as it works and is easy to use. 
>Unfortunately, what's more likely is that it won't work and won't be easy to 
>use if it's design is complex - a poor designer doesn't radically change the 
>way they do things when they come to the GUI and complexity tends to compromise
>reliability. 

I think we're both in agreement here.

>:Should one reject Ada out of hand, because
>:mixin inheritance in Ada using generics is "inelegant" compared to using
>:multiple inheritence in Eiffel?
>
>No, but it may mean that you're not able to model things as directly as you 
>might otherwise.

Spoken like a true afficionado of inheritence!  Well, I have some more news
for you, Don.  Nature (interpret that to mean God, if that suits you) has
chosen aggregation as the essential means of systems construction.  Oh, by
the way, artificial ("man-made") systems are built using aggregation too! 
Imagine that!

In spite of what you may have heard, your dishwasher, your car, your watch,
and even you are constructed using aggregation.  Last time I checked,
neither my computer (my little Mac, bless it), nor my stereo, nor my
microwave oven were constructed using inheritence - not even (gasp!)
multiple inheritence.  Say it ain't so, Joe!

How is this even possible? the dear Eiffel reader must be wondering.

Oh, yes, I know the argument: Humans use classification to simplify things,
so we should use classification to build software, blah blah blah.  Well
here's the real scoop: humans use _abstraction_ to simplify their world. 
Humans view and build systems as multi-level, heirarchical structures,
using _aggregation_.  So why build software systems any differently?

In spite of the propaganda enunciated by certain computer scientists, real
software systems do get built without inheritence.  A lone voice in a
chaotic world, JP Rosen, says it clearly enough:

"Once again, composition will exhibit a lower complexity and a greater
security at the cost of ease of design.  For small-sized, quickly developed
projects, classification can be an efficient method.  But for large-scale,
long-lasting projects, composition is necessary to ensure control on the
overall complexity."  - JP Rosen, What Orientation Should Ada Objects
Take?, CACM, Nov 1992 (Vol 35, No 11)

If neither I nor Jean-Pierre can convince you of the efficacy of
aggregation over inheritence, then perhaps these authors can:

Hierarchically Organized Systems In Theory & Practice
Paul Weiss

Theory of Hierarchical, Multilevel Systems
Mesarovic, Macko, Takahara

Hierarchical Structures
Whyte, Wilson, and Wilson

Hierarchy Theory
Howard Pattee

And by all means read the chapter The Architecture of Complexity, in 

The Sciences of the Artificial 
Herbert Simon

which just came out in a brand spankin' new 3rd ed.

(Oh, Herb won a Nobel prize, by the way.)

And if that isn't enough, maybe the Gang of Four can put you over the edge:

"Favor object compostion over class inheritance." -- p. 20 of Design
Patterns, by Gamma et al


The argument that in Ada, "you can't model things as directly as you might
otherwise," is completely specious.  Just the opposite is true, in fact. 
Ada has a very rich type system, specifically designed to allow you to
"directly model" logical entities, and especially physical entities, as
would be necessary for its intended domain, embedded systems.

Let's consider a simple example, from Ada: Language and Methodology, by
Watt, Wichmann, and Findlay (the "famous" book in which Tony Hoare tepidly
endorses Ada in the Foreward).

Suppose we need to write a disk controller.  We manipulate the disk through
a disk control block, located at memory address (octal) 77430.

The block comprises 2 16 bit words: the function code and some status bits
are located in upper byte of the first word, and the disk address is the
second word, ie

type Function_Code is (Read, Write, Write_With_Check, Seek);

for Function_Code use
  (Read => 2#0000#,
   Write => 2#0010#,
   Write_With_Check => 2#0100#,
   Seek => 2#1000#);

for Function_Code'Size use 4;

type Disk_Control_Block is
   record
      Code : Function_Code;
      Write_Not_Permitted : Boolean;
      Disk_Busy : Boolean;
      Disk_Off_Line : Boolean;
      Disk_Address : Interfaces.Unsigned_16;
   end record;

for Disk_Control_Block use
   record
      Code                              at 0 range 0 .. 3;
      Write_Not_Permitted at 0 range 5 .. 5;
      Disk_Busy                    at 0 range 6 .. 6;
      Disk_Off_Line               at 0 range 7 .. 7;
      Disk_Address              at 2 range 0 .. 15;
   end record;

for Disk_Control_Block'Size 32;

Control_Block : Disk_Control_Block;
for Control_Block'Address use 8#77430#;

Now, what were you saying about not be able to model the problem directly?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

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

[Nasser]

In article <mheaney-ya023680001707970007130001@news.ni.net>, mheaney@ni.net
says...
>
>Spoken like a true afficionado of inheritence!  Well, I have some more news
>for you, Don.  Nature (interpret that to mean God, if that suits you) has
>chosen aggregation as the essential means of systems construction.  

So, how does one explain what genetics tells us about DNA duplication
ftom parents to their children? How do you explain that green skinned people
produce green skinned people? and taller people most will produce taller
people? this is all nature at work, and each new creation of nature 
has inherited propertites of eariler generations.

offcourse, the human body is build by aggregation (eyes, ears, legs, arms,
etc.), but the poperty that those pieces have are mostly inherited.

As for aggreation vs. inheritence, for me, the most important thing is
to be to do software reuse as easily as possible, which methodology one 
chooses to drive towardes this, is just detailes. I think Ada is the best
language I have programmed with to enable code resuse.

I happend to think aggregation seems 'easier' to work with, but may be 
that becuase I have not done allot of inheritence. Also inheritence, 
by its nature, implies code coupling between the base and the children. 
If one chances the base, then ALL of its children behaviours will change, 
while in aggregation, one "client" can choose not to use the new 
changed/modified aggregate component, while the rest of the clients who 
used the common component can 'upgrade' to the new one.  
  

Nasser

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

[Brian Rogoff]

On 19 Jul 1997, it was written:
> In article mheaney@ni.net says...
> >Spoken like a true afficionado of inheritence!  Well, I have some more news
> >for you, Don.  Nature (interpret that to mean God, if that suits you) has
> >chosen aggregation as the essential means of systems construction.  
> 
> So, how does one explain what genetics tells us about DNA duplication
> ftom parents to their children? How do you explain that green skinned people
> produce green skinned people? and taller people most will produce taller
> people? this is all nature at work, and each new creation of nature 
> has inherited propertites of eariler generations.

I think it is a gross error of reasoning to suggest that OO inheritance is 
somehow "natural" because we use the same word "inheritance" to describe 
the process of the passing of genetic material from a biological entity to 
its offspring. I suppose poorly designed inheritance hierarchies must also 
be natural, since in nature we have examples of snippets of genetic
material being transferred by virus. Reasoning by analogy is particularly
suspect here.

> I happend to think aggregation seems 'easier' to work with, but may be 
> that becuase I have not done allot of inheritence. Also inheritence, 
> by its nature, implies code coupling between the base and the children. 
> If one chances the base, then ALL of its children behaviours will change, 
> while in aggregation, one "client" can choose not to use the new 
> changed/modified aggregate component, while the rest of the clients who 
> used the common component can 'upgrade' to the new one.  

This part is right. I tend to think that inheritance and dynamic dispatch 
should be used sparingly. GUI programming is one place it seems to be 
effective. Interpreters can also benefit in some places from an "OO" 
approach. But aggregation is really ubiquitous.

IMO, one of the big mistakes of modern CS theory is the emphasis on
"better" type systems (OO type systems are the rage) over  better control
structures. Hopefully some of us Ada programmers will get a chance to
experiment with way more powerful control structures when GNAT 3.10 comes
out and some SNOBOL 4 capabilities become available.

-- Brian
 

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

[Jon S Anthony]

In article <5qs47k$duf@drn.zippo.com> Nasser writes:

> In article <mheaney-ya023680001707970007130001@news.ni.net>, mheaney@ni.net
> says...
> >
> >Spoken like a true afficionado of inheritence!  Well, I have some more news
> >for you, Don.  Nature (interpret that to mean God, if that suits you) has
> >chosen aggregation as the essential means of systems construction.  
> 
> So, how does one explain what genetics tells us about DNA duplication
> ftom parents to their children?

It is pretty clear that Mathew is _not_ discussing this style of
inheritance - a type of genealogy inheritance.  If you want to draw
this sort of analogy into it, then note: OOPL classification style
inheritance is like Linean systematics, while what you are talking
about is akin to phylogentic systematics (a kind of cladistics).  The
semantics of these are totally different.


> offcourse, the human body is build by aggregation (eyes, ears, legs, arms,
> etc.), but the poperty that those pieces have are mostly inherited.

Actually, as long as you keep your terms and model types straight, the
"parts" are indeed inherited (in the phylogenetic sense).


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

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

[Jon S Anthony]

In article <Pine.SGI.3.95.970720113201.28934B-100000@shellx.best.com> Brian Rogoff <bpr@shellx.best.com> writes:

> > So, how does one explain what genetics tells us about DNA duplication
> > ftom parents to their children? How do you explain that green skinned peo
...
> I think it is a gross error of reasoning to suggest that OO inheritance is 
> somehow "natural" because we use the same word "inheritance" to describe 
> the process of the passing of genetic material from a biological entity to 
> its offspring.

Correct.  The problem is in using the same term "inheritance" in
settings where its meaning (and hence the semantics of the model type
involved) are completely different.  I discussed this a little in an
attendant post...

> This part is right. I tend to think that inheritance and dynamic dispatch 
> should be used sparingly.

Absolutely agreed.

> approach. But aggregation is really ubiquitous.

Exactly.


> IMO, one of the big mistakes of modern CS theory is the emphasis on
> "better" type systems (OO type systems are the rage) over  better control
> structures. Hopefully some of us Ada programmers will get a chance to
> experiment with way more powerful control structures when GNAT 3.10 comes
> out and some SNOBOL 4 capabilities become available.

Could not agree more.  This is sort of a case of the "revenge effect".
Used sparingly and with good judgement, "OO" stuff is quite effective
and useful.  Unfortunately, it has somehow become interpreted that
this means it should be used everywhere and that it is universally
good in development.  Completely fatuous.  Worse - outright
_clueless_.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

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

[Robert C. Martin]

Matthew Heaney wrote:
> 
> Oh, yes, I know the argument: Humans use classification to simplify things,
> so we should use classification to build software, blah blah blah.  Well
> here's the real scoop: humans use _abstraction_ to simplify their world.
> Humans view and build systems as multi-level, heirarchical structures,
> using _aggregation_.  So why build software systems any differently?

I sympathize with this point of view.   But let me add a bit more to
the heresy.  Inheritance, as defined in OO languages, *is* a form of
composition!  A derived class is *composed* of its base class along
with any other elements unique to the derivative.  

In the specific case of abstraction by polymorphism, the derived
classes that implement the interface of the base class are *composed*
of the interface of the base and the implementation of the derived.

Any of the abilities of inheritance can be achieved through 
composition, without the use of inheritance.  However, such techniques
can be inconvenient and error prone.  Inheritance is a very nice
language feature when you want to compose an interface with an
implementation.
> 
-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

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

[Andrew Dunstan]

In article <Pine.SGI.3.95.970720113201.28934B-100000@shellx.best.com>, Brian Rogoff <bpr@shellx.best.com> wrote:

>I think it is a gross error of reasoning to suggest that OO inheritance is 
>somehow "natural" because we use the same word "inheritance" to describe 
>the process of the passing of genetic material from a biological entity to 
>its offspring. I suppose poorly designed inheritance hierarchies must also 
>be natural, since in nature we have examples of snippets of genetic
>material being transferred by virus. Reasoning by analogy is particularly
>suspect here.
>

Right. I once heard a computer scientist, who now occupies a prestigious 
chair, say that only left derived top down parsers should be used because 
that is how people read natural language. Not only is this a dubious 
proposition at best (I have seen research indicating that bottom up LR 
parsing has significant analogues in the way we read). but I can see no 
reason why a computer parser  should mimic a human. So let's steer clear of 
dubious analogies.

cheers

andrew

-------------------------------------------------------------------------
  There's nothing either good or bad, but thinking makes it so - Hamlet
  http://www.gr-lakes.com/~andrew (including PGP key)
  PGP Key fingerprint = 5C 44 7D E4 76 A3 31 DE  3D 11 FA 15 4D 87 1F 5E
-------------------------------------------------------------------------

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

[Ell]

Robert C. Martin (rmartin@oma.com) wrote:
:
: Matthew Heaney wrote:
: > 
: > Oh, yes, I know the argument: Humans use classification to simplify things,
: > so we should use classification to build software, blah blah blah.  Well
: > here's the real scoop: humans use _abstraction_ to simplify their world.
: > Humans view and build systems as multi-level, heirarchical structures,
: > using _aggregation_.  So why build software systems any differently?
 
: I sympathize with this point of view.   But let me add a bit more to
: the heresy. Inheritance, as defined in OO languages, *is* a form of
: composition!  A derived class is *composed* of its base class along
: with any other elements unique to the derivative.  

What's so heretical about using aggregation in OO?  That's what MS COM
technology is based on.

BTW, you try to make it seem that you are holding a noble viewpoint worth
adopting in the face of the OO establishment.  But in fact diving right
into coding without holistic analysis, taking a piecemeal approach, and
not fully basing oneself in the domain model have been widely practiced in
software development by hackers and Coboy Coders everywhere for years and
years. 

Elliott
-- 
"The domain object model is the foundation of OOD."

"We should seek out proven optimal practices and use them."

	~~ The writer