Re: Ichibah flames, and flames out over, Ada 9X

[stt@spock.camb.inmet.com (Tucker Taft)]

In article <1993Feb25.170827.2178@ennews.eas.asu.edu> 
  koehnema@enuxhb.eas.asu.edu (Harry Koehnemann) writes:

>. . . I hear all this hype about tagged types 

I'm glad to know that at least we are getting some "hype" out
on Ada 9X.  As any good marketer knows, publicity of any kind is often
better than no publicity at all. ;-)

> . . . and I see a
>few small examples of how they're used with packages/generics/...,
>but has anyone implemented a few OO problems with each and compared
>them? Semantically, it was easier to add extensiosn to Ada than a
>class construct.  But, I think the jury's still out on the "type
>extensions > classes" question.

Actually, there really is not that much difference.  A class-based language
happens to have type = module, whereas in package/module-based languages,
types are declared inside of modules.  If you only declare one type
in a module, you effectively achieve type = module.  It is interesting
that in C++, a need for nested types/classes has emerged, so that one can have
"helper" types (for example an enumeration type) local to a class.
So even in C++ one can end up with multiple types per module.
The details are slightly different, but the functionality and capability
are largely the same.  Also, it is worth mentioning that languages like
CLU adopted type=module even without having OOP.  So this choice
ultimately has relatively little to do with the OOP functionality.

Ada 83 happened to chose the module/package approach, and it seemed unwise to
create an unrelated type=module OOP "corner" for Ada 9X, just to add dynamic
binding and full inheritance.  We felt it was much more consistent to
enhance the existing simple inheritance already provided by "derived types"
to provide type extension.  Dynamic binding has almost nothing to do
with type=module vs type-inside-module, and can be added to either quite
straightforwardly.

But in any case, the debate between Jean Ichbiah and the 
Ada 9X Mapping/Revision Team (MRT) was not really about 
"classes" vs. "type extensions," it was whether we 
should use the keyword "class" in the syntax for type extensions.
The MRT felt that it would simply further confuse the issue by trying
to cloak our type extensions in the word "class."  So the issue was
really about which syntax was most suggestive of the semantics --
a kind of issue that unfortunately does not lend itself to objective
debate, even though it creates strong feelings on both sides.

>And, maybe it's not as much close minded as cost.  Someone told me
>to invest all this money up front on reusable class libraries.  Now
>you want me to switch to a non class-based language?  Doubt it will
>happen.  

Even if Ada 9X were "class-based," this would not magically create
interoperability between C++ and Ada 9X implementations or their
libraries.  In fact, there is no fundamental semantic barrier 
to interoperability between C++ and Ada 9X.  For almost every
feature of the two languages, there is a very direct mapping.

The real barrier to interoperability is an implementation one.  Both
languages allow many alternatives in implementation strategy.
Achieving interoperability between two different implementations of
C++ is hard enough.  The same goes for Ada.  Achieving interoperability
between a given implementation of C++ and one for Ada 9X is highly
doable, but it is by no means trivial, and requires an implementor
to focus on the goal early in the design of the run-time model.
Since both GNAT and G++ will share a backend, it will be interesting
to see how much interoperability emerges "by accident" and how much
"by design." (I don't know what are the goals for interoperability of
GNAT and G++.)

> . . . People seem to use what they like and OO developers like a
>class construct.  Tagged types are not new and for some reason or
>another were never embraced by the OO community.

It is interesting to see the statement that "tagged types are not new."
Presumably you mean "OOP with a type-inside-module language is not new."
True.  You might want to look at Turbo Pascal with Objects, or 
Apple's ObjectPascal.  These represent quite successful "type-inside-module"
OOP languages.  But of course, C++ is the dominant player these days,
and since C didn't have a preexising module facility (other than the
"source-file = module" concept), it made good sense to kill two birds
with one stone and get modules and abstract data types in one "swell foop."

Despite the enormous success of C++, there is still a lot of (at least 
academic) interest in the new OOP languages Modula-3 and Oberon-2, both 
of which have gone the type-inside-module.  So it may be too early to say that
"we have a winner."  And for that matter, once you start using one
of these languages, you will probably discover the type=module vs.
type-inside-module choice has very little effect on how you design
and structure your OOP systems.  You will end up creating groups of
types whether or not the language directly supports the concept of
"modules."  Similarly, you will often end up having one (primary) type 
in a module, even if the language allows multiple such types.
The structure of the problem will probably have more effect on 
the structure of the program than does the type=module vs. type-inside-module
decision of the language designer.

> . . .Should be an
>interesting next few years.

No debate there.

Independent of this type=module vs. type-inside-module issue, 
there are in fact some differences between the Ada (83 and 9X) 
language design philosophy and the C++ philosophy.  But even
in the fundamental philosophy, there has been more convergence
than divergence as time has passed.  

Ada is oriented toward maximizing the number 
of errors that are caught at compile-time, and then,
for those that can't be checked at compile-time, there is a full
set of run-time checks.  The run-time checks can be supressed, but
many compiler vendors take it as a challenge to provide sufficient
optimization that the run-time checks can be left "on" while still
achieving production-level performance.  

C++ clearly has added more compile-time 
checking possibilities, first by providing for function 
"prototypes" (since adopted by ANSI C), second, and perhaps more importantly,
by adding support for abstract data types, and third (most recently),
by adding a full template capability that minimizes the number of
"casts" that must be written outside of the implementation of a template.
Nevertheless, C++ has avoided defining run-time checks (although they are 
adding exception handling so that abstract data types can provide them in
a convenient way).  Now that C++ is being standardized, more rather
than less checks are being defined (e.g., some kind of checked "down-cast").

Interestingly, a number of tools have sprung up to 
provide run-time checks for C++ programmers (e.g. CenterLine's
ObjectCenter, Pure Software's Purify).  However, the run-time checks
provided by such tools currently impose a higher run-time 
overhead than the corresponding (standardized) checks in Ada, 
because they haven't been integrated in with the optimizer, and in 
some cases, are performed by interpreting rather than by direct execution.
The fact that these checks are provided by separate tools (much
as "lint" used to be used instead of having function prototypes) reflects
the C/C++ philosophy of keeping the language semantics simple, and leaving
checking to the environment.  The advantage of this approach is offset
somewhat by the lack of portability in what checks any given environment 
enforces, and in the (currently significant) difference in performance in the 
presence of checks.

If there were a clearly "right" answer, then we would only need one
language.  At any given time, one language, one computer company, one
ISA, one design approach will tend to be dominant.  
However, over time, things change.  It is hard to predict 
whether C++ (and OOP for that matter) will remain predominant indefinitely, or
whether languages that make slightly, or radically, different choices
will emerge to take its place for "mission-critical" systems programming.  

We have tried to make Ada 9X as powerful, flexible, uniform,
and usable a systems-programming language as possible, within the 
constraints of its existing "safety-first" 
philosophy, the time available for revision,
and the desire to minimize new complexity in the language, while
eliminating what old complexity exists in the way of unnecessary
arbitrary restrictions and special cases.  Or, in other words, we
have tried to minimize any *techical* barriers to its use.  Other
people (such as the Ada 9X Project Office) have taken it upon
themselves to try to minimize the non-technical barriers (e.g. by
funding GNAT, encouraging Ada-based courses in universities, arranging
low-cost compilers for academic use, etc.).  

Time will tell whether Ada 9X emerges as an attractive 
and viable alternative to C++, or whether some
as yet unnamed language emerges, or whether C++ remains 
the predominant language indefinitely.  The nice thing 
about competition is that, in general, the users benefit 
in any case, since all of the alternatives are being 
improved and the number of good choices keeps increasing.

>--
>Harry Koehnemann			Arizona State University
>koehnema@enuxha.eas.asu.edu		Computer Science Department

S. Tucker Taft    stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138