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

[mheaney@ni.net (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