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

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

[John Goodsen]

koehnema@enuxha.eas.asu.edu (Harry Koehnemann)

>In article <1993Feb17.065421.12021@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (Davi
d Weller) writes:
>>Speaking of tagged types,
>>it was my impression that this was Mr. Ichbiah's most sour grape.
>>He was rather insistent on creating a class-based language, rather
>>than the tagged types that we have now.  Although I agreed with him
>>on quite a few points, Tucker's counterpoints were far more
>>compelling.  
>
>Now that's interesting, if it is indeed true.  Technical merits are
>not the sole consideration for any design.  WHile the package/type
>extension approach may have advantages over a class based approach,
>it also has disadvantages - perhaps the largest being understanding
>by developers.  Class based langauges are common, their usage well
>understood (well, as understood as things get in CS), and most
>importantly, are currently embrassed by OO developers.  Type
>extensions (tagged types), while by no means a new concept, are not
>seen in the popular OO langauges.
>
>I think it will be interesting to see how the OO community that Ada
>seeks to crack will embrace extensions as a construct for inheritance.
>Particularly considering their past acceptance of the construct.  I
>also think the Ada community has a big sell ahead of itself.  Not that
>it can't be done, but "technical merit" does not directly lead to
>"popular" or "used" (ask FORTRAN and COBOL - and unfortunately Ada83).
>

How true.  A technological feasible solution in no way gaurantees
a success.  There is a concept of "perceived" need versus "actual"
need.  You don't market to "actual" needs, but to "perceived" needs.
The perception in the OO community is that the class is the natural
structuring concept.  The Ada 9X approach to classes, while technically
feasible is going to have a tough sell into NEW markets, because it
lacks the perception necessary to be embraced by a mainstream of
OO developers.  In particular, the concept of a "class" as a basic
object oriented structuring mechanism.  This same argument also
applies to the lack of direct support for multiple inheritance in Ada9X.  
While there have been proposals on how to perform MI using generics
or method delagation (which are still debatable), the perception 
of multiple inheritance as a core component of the language is not
there and will also hinder the marketing of Ada into NEW markets ...
While those of us who already know and like Ada are excited about
9X features, these 2 lacking perceptual needs (Class level packaging
and Multiple Inheritance) will negatively impact the growth potential
of this powerful language.

Before the flame war on this starts again, execute the following:


 If Flamer Has_Not_Read(DRAGOON) then
    Redirect_Flames ( to => "/dev/null" );
 end if;

--
John Goodsen
Software Process & Environments
EVB Software Engineering
jgg@evb.com



-- 
John Goodsen
Software Process & Environments
EVB Software Engineering
jgg@evb.com

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

[agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!ne]

In article <1993Feb24.211028.8076@evb.com> jgg@evb.com (John Goodsen) writes:
>How true.  A technological feasible solution in no way gaurantees
>a success.  There is a concept of "perceived" need versus "actual"
>need.  You don't market to "actual" needs, but to "perceived" needs.
>The perception in the OO community is that the class is the natural
>structuring concept.  The Ada 9X approach to classes, while technically
>feasible is going to have a tough sell into NEW markets, because it
>lacks the perception necessary to be embraced by a mainstream of
>OO developers.  In particular, the concept of a "class" as a basic
>object oriented structuring mechanism.  This same argument also
>applies to the lack of direct support for multiple inheritance in Ada9X.  
>While there have been proposals on how to perform MI using generics
>or method delagation (which are still debatable), the perception 
>of multiple inheritance as a core component of the language is not
>there and will also hinder the marketing of Ada into NEW markets ...
>While those of us who already know and like Ada are excited about
>9X features, these 2 lacking perceptual needs (Class level packaging
>and Multiple Inheritance) will negatively impact the growth potential
>of this powerful language.
>
>Before the flame war on this starts again, execute the following:
>
>
> If Flamer Has_Not_Read(DRAGOON) then
>    Redirect_Flames ( to => "/dev/null" );
> end if;
>
>--
>John Goodsen
>Software Process & Environments
>EVB Software Engineering
>jgg@evb.com

Well, since I have not only read DRAGOON (actually, the _book_ has a
different title :-), but am also working with Colin Atkinson on 
extensions to DRAGOON (and translation thereof into Ada 9X), I feel
qualified to respond to Mr. Goodsen's points.  WARNING: This won't be
a flame -- hope I didn't disappoint anybody. :-)

The 9X community, IMHO, has struggled with this problem, that the
_perception_ that 9X will be a "weaker" language than C++ because
it lacks MI and is not class-based.  Indeed, this was the crux of my
argument against tagged types many months ago (which lead Jean Ichbiah
to chime in with me on this issue, which lead to the tagged vs.
class debate, which lead to "The Vote", which lead to Mr. Ichbiah's
resignation as a DR, which lead to a GCN article on it, which lead to
my reply here, which created this thread.  Ain't it funny how things
come back to haunt you?).  Since that time, I've had several frank
discussions with Tucker, who has done a commendable job of creating
an extension to Ada which supports features that are necessary for
Good Software Engineering(tm).

Ada 9X will indeed have a "tough sell" to the unwashed masses who
believe that MI is a Good Thing for an OO language.  Adding MI
was discussed at great length on here a couple of years ago, culminating
with TUcker's survey of OO developers (trying to find where MI
was actively/genuinely used in _real_ OO projects).  The survey
revealed little, if any use.  And, as I recall, many places indicated
they forbid the use of MI (lattice effects tucked in a class four levels
away are HORRIBLE to fix!).  After careful consideration, the 9X MRT
decided that MI was too difficult to add into Ada SAFELY without adding
excessive overhead.  I'm dredging this all up from memory.  Perhaps
Tuck or Ed Schonberg can throw some more comments in here.  

As for Ada not being class-based -- GREAT!  I'm convinced that, in the
long run (which Ada was designed for, right? :-), tagged types will
prove FAR more versatile.  The problem is SELLING the concept to people
who are so closed-minded as to believe that class-based languages are
the "bee's knees" for OO (then again, one could say us "taggers" are
close-minded, huh?).  Mind you, I was NOT an easy convert on this issue.
I raised my share of stink on the 9X mailgroup (look back in Aug/Sept 92
timeframe).

I'd be interested to hear what your arguments are for making Ada
class-based (meaning, I haven't heard a NEW one for months).  Not
that it matters anymore anyway.

Oh, one final sales pitch for DRAGOON: Seems that the Italian company
that markets DRAGOON isn't having much success in the US, since there
is no marketing agency within the US.  If you know of a software house
that would liek to court TXT Inginerie to market DRAGOON within the US,
that would be great.  I think DRAGOON is a great language, and can grow
with more US usage.  Any takers?

dgw

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

[Harry Koehnemann]

In article <1993Feb24.224827.27672@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (David
 Weller) writes:
>As for Ada not being class-based -- GREAT!  I'm convinced that, in the
>long run (which Ada was designed for, right? :-), tagged types will
>prove FAR more versatile.  The problem is SELLING the concept to people
>who are so closed-minded as to believe that class-based languages are
>the "bee's knees" for OO (then again, one could say us "taggers" are
>close-minded, huh?).

Hard to say.  I hear all this hype about tagged types 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.

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.  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.  Should be an
interesting next fwew years.
--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department

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

[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

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

[Dag Bruck]

In <comp.lang.ada> stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>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.  

It is worth pointing out that in many cases, classes in C++ are used
only as abstract datatypes, i.e., without using inheritance or virtual
functions.  This common use of classes is very close to Ada packages.

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

I would like to comment as a user of Purify.  Some of the overhead,
probably a significant portion, comes from checks that are not normally
done by a civilized compiler with run-time checks.  Purify will also
check all system libraries, e.g., your X11 library, which are normally
compiled without debugging and checks turned off to improve speed.

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

I think this has nothing to do with language semantics.  For example,
it is clear that accessing a piece of storage that was explicitly
deallocated is an error, in C++ as in any other language.  Few, if any,
language implementations check this, but Purify does.

I think this is a typical example where tools go beyond the language
implementation by adding checks that are not normally present, but
still does not add any semantics to the language.

There are of course other advantages to the tool approach.  In the
case of Purify, one advantage is that it can be used on code produced
by several compilers (but not any compiler, of course), which in some
sense increases portability.

Perhaps someone can answer this question: what kind of debugging
support (along the lines suggested above) will typical Ada
implementations give for unchecked deallocation?


			-- Dag

Re: Ada9X, DRAGOON, etc.

[David Weller]

In article <SRCTRAN.93Feb26102644@world.std.com> srctran@world.std.com (Gregory Aharonian) writes:
>
>    But Mike's statements implicitly contradict each other and portend
>a sad future for Ada9X - that it will be less accepted in the non-mandated
>world than Ada83.  I do not believe that the current Ada vendors will be
>able to change their ways.  Even now, one of them, Rational, is gradually
>moving away from the Ada world to the C++ world (as evidenced by the ads
>with Grady Booch's smiling face pushing the C++ version of the Booch
>components).
>

Your claim that Rational is moving away from Ada is false.  You observed
Rational expanding into the C++ domain (which is a good thing) and
concluded a weakening in the Ada domain.  Nothing is further from the truth.
Also, keep in mind, Grady's smiling face pushing conferences like
"C++ by Design" does not imply Rational is throwing their hands up
on Ada.  Grady doesn't always speak for Rational.  

>Greg Aharonian
>Source Translation & Optimization
>"Fund me or flame me - anything else is an insult"
>-- 

OK, I guess it was a flame :-)

dgw
>**************************************************************************
>Greg Aharonian
>Source Translation & Optimiztion
>P.O. Box 404, Belmont, MA 02178

Re: Ada9X, DRAGOON, etc.

[Michael Feldman]

In article <1993Feb26.184152.10231@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (David Weller) writes:
>In article <SRCTRAN.93Feb26102644@world.std.com> srctran@world.std.com (Gregory Aharonian) writes:
>>
>>    But Mike's statements implicitly contradict each other and portend
>>a sad future for Ada9X - that it will be less accepted in the non-mandated
>>world than Ada83.  I do not believe that the current Ada vendors will be
>>able to change their ways.  Even now, one of them, Rational, is gradually
>>moving away from the Ada world to the C++ world (as evidenced by the ads
>>with Grady Booch's smiling face pushing the C++ version of the Booch
>>components).
>>
>
>Your claim that Rational is moving away from Ada is false.  You observed
>Rational expanding into the C++ domain (which is a good thing) and
>concluded a weakening in the Ada domain.  Nothing is further from the truth.
Time will tell.

>Also, keep in mind, Grady's smiling face pushing conferences like
>"C++ by Design" does not imply Rational is throwing their hands up
>on Ada.  Grady doesn't always speak for Rational.  
IMHO, Grady needs to make more of a distinction between his responsibilities
for Rational and the other things he does. If I recall, the C++ By Design"
"conference" (actually I think it was more like an expensive seminar)
gave his affiliation as Rational. Under those circumstances, we can assume
safely that he was speaking for his employee. If Grady was free-lancing
here, his affiliation should not have been given as Rational.

Just my 2 cents. I have the same problem sometimes, by the way.

Mike Feldman
>
>>Greg Aharonian
>>Source Translation & Optimization
>>"Fund me or flame me - anything else is an insult"
>>-- 
>
>OK, I guess it was a flame :-)
>
>dgw
>>**************************************************************************
>>Greg Aharonian
>>Source Translation & Optimiztion
>>P.O. Box 404, Belmont, MA 02178
>
>