Re: Ammo-zilla

[Tucker Taft <stt@averstar.com>]

Charles Hixson wrote:
> 
> I am continually attracted to Ada, however:
> The Ada approach to memory management reminds me of the PL/1 approach,
> only simplified a bit.  I suppose that you can say that it's better than
> C++, but that's *REALLY* faint praise.  There are a lot of details that
> I don't fully understand, but this is one of Ada's weaker aspects.  The
> second is the syntax used in "object" declaration.  Very clumsy.
> 
> Now I *do* understand that the reason for this approach is (partially
> the date of design but also) to allow statically linked programs to be
> small enough for embedded systems, etc.  And it is indeed necessary to
> enable this.  But the cost of a unified design of this nature is that,
> e.g., garbage collection is eliminated from the language.  (The syntax
> is mainly due to early design.)  I feel relativly certain that if the
> language were to be designed today that many things would have been done
> differently.

That's an interesting question.  I have on occasion since we finalized
the Ada 95 design thought about how I might design a language if I
could really start from scratch.  After a huge amount of horsing around,
I end up surprisingly close to where Ada 95 is now.  For example,
you mention the "clumsy" syntax associated with object declarations.
It is interesting to note that Haskell, one of the more elegant
functional programming languages out there, has essentially the
identical object approach as Ada 95, as does CLOS, common lisp object 
system. 

If you are used to the notion of an abstract data type, defined by a
type and a set of operations, and then you decide you want to support
extensibility of abstract data types, then you end up at something
very much like Ada 95, Haskell, or CLOS, with the 
"operation(operand, operand, ...)" or "operand <operator> operand"
or "object := operation(operand, operand,...)" syntax familiar from
theoretical mathematics and logic.  If you instead focus on
updating objects as the primary operations of interest, then you end up with
the <obj>.<operation> syntax.  In some ways, the Ada 95 syntax is
more sympathetic with the "value-oriented" (i.e. functional) way
of thinking than the "object-oriented" (i.e. side-effecting) way
of thinking.  The net effect, in any case, is that you can more easily
write in a "functional" style in Ada 95 where there is less use of
heap-resident read/write objects, and more use of values (rather than 
objects) of an abstract type being passed around, assigned, declared, etc. 

One interesting side note -- because Ada is a multi-tasking language,
the objects that are designed to retain read/write global state need some kind
of synchronization/protection.  For such objects (tasks and protected
objects), the object.operation(...) syntax is intentionally chosen, because
there is clearly a special role played by the "target" task or
protected object.  By contrast, for value-oriented operations like
set union, the symmetrical syntax of "union(set1, set2)" seems far
more intuitive than "set1.union(set2)", and the symmetrical syntax
is used for such operations in Ada. 

Speaking from experience of using Java, although the object.operation(...)
syntax can be convenient sometimes, surprisingly often I find conceptual
operations for which there are at least two conceptual operands, generally
of different types/classes, that are just as appropriate (or perhaps,
just as inappropriate) as the "prefix" operand in the object.operation(...)
syntax.  Generally, I suppose the distinction is between operations whose
primary role is to update some operand (in which case, it makes sense
to be identified specially), versus those operations that create some
output given two or more inputs, in which case it is arbitrary which
of the inputs ends up being put "out front" in the object.operation(...)
syntax.

As usual in all such discussions, your mileage may vary...

> David Botton wrote:
> 
> > > Now that's an interesting comment, because to me C++ and Ada
> > > are identical in this particular department, can you explain
> > > why you think Ada is better wrt memory leaks?
> >
> > As a result of the excellent design of Ada, I use far more static
> > allocation then dynamic resulting in less chance of memory leaks. Of
> > course once you start playing with the heap its all about personal
> > programmer discipline.
> >
> > David Botton

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA