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

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

[agate!howland.reston.ans.net!sol.ctr.columbia.edu!The-Star.honeywell.com!]

In article <SRCTRAN.93Feb16213209@world.std.com> srctran@world.std.com (Gregory
 Aharonian) writes:
>   The following article was in the February 15, 1993, issue of Government
>Computer News, cover page.  It mentions an Internet exchange which apparently
>skipped over comp.lang.ada.  Anyways, here it is.
>
>Greg Aharonian
>Source Translation & Optimization
>
>[GCN Article Deleted]
>
>Again, did this stuff ever float over comp.lang.ada ?

No, in fact, it didn't.  Not that I really felt it should.  I do
believe, however, that his "goodbye letter" can be found somewhere
in the Mapping Revision Team comments (available via public ftp from
ajpo.sei.cmu.edu under the directory public/ada9x/mrtcomments).  I'd
suggest that you look back around late October.  I seem to recall he
wrote that letter at the same time Tri-Ada was going on.  I believe
he also used it as a platform to make a final protest against the
"with private" clause for tagged types.  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.  

Personally, I'm diasppointed that Jean left.  When a knowledgeable
antagonist leaves a group like the MRT's reviewers, there's always
a chance that the health of the 9X project will suffer.  However, if
you'll look at the MRT comments, you'll find that there's still
PLENTY of knowledgeable antagonists out there.  Right, Tuck? :-)

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

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

[agate!howland.reston.ans.net!wupost!darwin.sura.net!mlb.semi.harris.com!d]

In article <1993Feb17.065421.12021@sei.cmu.edu>, wellerd@ajpo.sei.cmu.edu
(David Weller) writes:
|> In article <SRCTRAN.93Feb16213209@world.std.com> srctran@world.std.com
|> (Gregory Aharonian) writes:
|> >
|> >Again, did this stuff ever float over comp.lang.ada ?
|> 
|> No, in fact, it didn't.

I don't believe Jean's letter and Tucker's response were ever 
posted to *any* USENET newsgroup.  The copies I have were sent 
to the Ada9X mailing lists (which may be where the 'Internet' 
thing came from).

-- 
Scott McCoy	Harris ISD	Opinions expressed are my own.
Staff Eng - SW	Internet: 	smccoy@dw3g.ess.harris.com

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

[asuvax!ennews!enuxhb.eas.asu.edu!koehnema]

In article <1993Feb17.065421.12021@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (David
 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).
--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department

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

[Robert I. Eachus]

     There are two intertwined issues here.  Jean sees beauty as an
important facet of programming language design, and his major
disagreement with Tucker is on exactly this issue.  He feels that wide
acceptance of Ada 9X requires that it be more elegant than Ada 83.  At
the current state of the process this is clearly not the case, but
knowing the people on board, especially Mike Woodger, I have to
believe that the final standard document will be much more elegant
than the current version of the ILS.

      But elegance also applies to the programs written in Ada 9X.
Jean send a message to the list saying it was now time to consider the
style issues and "with null" was first on the list.  While this phrase
is now gone in some places if not all, several people including Jean
felt that the keyword should be class, not tagged, and should precede
not follow the "type XXX is."  (Ada 83 does have both: "task type FOO
is..." and "type BAR is limited private;" so consistancy is not an
issue.)

     At the WG9 meeting in Salem, there was a vote to decide between
the two proposals (by countries since this was an ISO meeting).  The
vote was two to two with six abstentions.  (The US delegation felt the
appropriate position was to abstain initially then throw our support
to the winning side.  Oops!)  I think that overall the vote really
reflected a feeling that there might be a better alternative, but that
there really was no major techincal reason to favor one over the
other. Unfortunately, at this point a better alternative would require
major technical advantages to make it in the language.

     Second, and the major reason I am writing this, please don't let
the presence mislead you about the OO features in Ada 9X.  Of course,
Jean feels that this misperception will kill Ada 9X...  The mechanisms
in Ada 9X provide the necessary missing key pieces in Ada 83 to
implement all OO idioms.  (With the possible exception of troublesome
uses of multiple inheritance.  At this point I am actually more
concerned that the MI mechanisms in Ada 9X will allow misuse, that
that any current MI design cannot be implemented.)

     Maybe I should elaborate.  In Ada 9X, it is possible/easy to
create classes intended as mix-ins.  Take it to an extreme, and all
but one root (class) type in your program can be implemented as a
mix-in.  That doesn't seem to lead to surprises.  It is also possible
to inherit from a single parent no matter how that parent was
designed.  Also a clear mental model.  When you mix the SI and MI
models, it is not clear that all the possible consequences are easily
predictable.  (But at least they are always well specified, which is
better than most languages with MI features.)

--

					Robert I. Eachus

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

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

[Mark A Biggar]

In article <1993Feb25.170827.2178@ennews.eas.asu.edu> koehnema@enuxhb.eas.asu.e
du (Harry Koehnemann) writes:
>... 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.

Most of the current OO comunity has never seen anything except C++, so
how could they have embraced anything else.  Note that CLOS in Common LISP
is not really class based (Class based: using simula like classes as the
major structuring and encapsulation method) and is really closer to
Ada tagged types then anything else.  Smalltalk is its own little world.
Everything else OO is either too academic or too little know to have had any
affect on any large portion of the current OO community.

--
Mark Biggar
mab@wdl1.wdl.loral.com

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

[David Emery]

Ed Schonberg @ NYU has done a study comparing C++ and Ada9X
implementations of a set of reusable components based on the Booch
components, I believe.  
				dave

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

[enterpoop.mit.edu!linus!agate!howland.reston.ans.net!paladin.american.edu]

In article <1993Feb25.235118.8156@wdl.loral.com> mab@wdl39.wdl.loral.com (Mark 
A Biggar) writes:

>Most of the current OO comunity has never seen anything except C++, so
>how could they have embraced anything else.  Note that CLOS in Common LISP
>is not really class based (Class based: using simula like classes as the
>major structuring and encapsulation method) and is really closer to
>Ada tagged types then anything else.  Smalltalk is its own little world.
>Everything else OO is either too academic or too little know to have had any
>affect on any large portion of the current OO community.
>
Correct! Much of the supposed OO community in industry is really the C++
community, which seems to think that the only way to do OO is the C++ way.
The most extreme case is those whose understanding of OO can be summarized
"I don't know much about it, but I've heard it's that stuff that C++ can
do that Ada can't." There's a LOT of this around, folks.

I think it was Robert Dewar of NYU who, some years ago in a discussion
about some Ada feature or other (maybe tasking), said "Look, you may
have one model in mind; Ada has another. Just because Ada didn't
adopt _your_ model doesn't make Ada wrong."

I think it's high time to look at Ada on its own merits, and consider
soberly and impartially whether Ada can do our job. We will get nowhere
continually comparing Ada to C++ as though C++ had a monopoly on truth.

Constantly asking "which is better" is futile, because nobody knows,
nobody _can_ know, and even the cost-effectiveness question can be
answered only after years of experience, and the answer _still_ will 
depend upon how the numbers are cooked.

Show me some _solid_ evidence about classes vs. tagged types. I claim
there is none and won't be for years. So let's get back to work.

This newsgroup somehow manages to get back around to this pi**ing match
every few weeks. I am thoroughly bored with it, and you must be too...

Mike Feldman

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

[Bob Munck]

In Volume 93 : Issue 89,
eachus@mitre-bedford.arpa (Robert I. Eachus) says:

> ... Jean send a message to the list saying it was now time to
> consider the style issues and "with null" was first on the
> list.  ... several people including Jean felt that the
> keyword should be class, not tagged, and should precede
> not follow the "type XXX is." 

Jeez.  It sounds like you guys are arguing over how many angels
can dance on a pin and Jean left in a huff because you decided
it was an odd number.  I mean, this is an ISSUE??!?

It seems to me that Ada is, right now, going through a serious
crisis at the level of pure survival.  Maybe there's a better
focus for all this energy and passion?

Bob Munck

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

[Don Tyzuk]

munck@STARS.RESTON.PARAMAX.COM (Bob Munck) writes:


>It seems to me that Ada is, right now, going through a serious
>crisis at the level of pure survival.  Maybe there's a better
>focus for all this energy and passion?

I agree. Although I am surprised at the lack of promotion of
the benefits of Ada by the military and the Ada developers, I
think I understand why. (but I won't ratlle on about something
that generates heat, but little light.)

What I would like, is some suggestions on what I can do as a
4th year CS student to educate my local community about Ada.

I am known at school to be interested in Ada, and I encounter
comments (sometimes from people who maybe should know better)
that are surprisingly ill-informed.

"Ada -- that's only for military apps, right?"

"It can't possibly run on your PC, can it?"

"Isn't Ada so big it is unlearnable by mere mortals?"

"C++ is the only way to go with OOPS."

So, netland, what should I do?  I think a short presentation
on Ada with a sidebar about 9X would go a long way to dispel
some myths.  This is all bearing in mind I am a Student and
may have limited credibility...


-- 
Don Tyzuk				| P.O. Box 1406
Jodrey School of Computer Science	| Wolfville, Nova Scotia
Acadia University			| CANADA     B0P 1X0
e-mail: don.tyzuk@acadiau.ca

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: Ichibah flames, and flames out over, Ada 9X

[news]

In article <1993Feb28.184206.27188@dragon.acadiau.ca>, 841613t@dragon.acadiau.ca (Don Tyzuk) writes:
 
> 
> What I would like, is some suggestions on what I can do as a
> 4th year CS student to educate my local community about Ada.

You should start by finding out who Charles Anthony Richard Hoare is, and 
what the ACM is, and what the Touring award is.  You should then find a
copy of the lecture which Mr. Hoare delivered on the occasion of his
receiving the Touring award from the ACM in 1980.  You should then
read that paper from beginning to end, and inform your local community
as to what you have learned.


-- 
Ted Holden
HTE

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

[Richard Pattis]

In article <314@fedfil.UUCP> news@fedfil.UUCP (news) writes:
>In article <1993Feb28.184206.27188@dragon.acadiau.ca>, 841613t@dragon.acadiau.ca (Don Tyzuk) writes:
> 
>
>You should start by finding out who Charles Anthony Richard Hoare is, and 
>what the ACM is, and what the Touring award is.  You should then find a
>copy of the lecture which Mr. Hoare delivered on the occasion of his
>receiving the Touring award from the ACM in 1980.  You should then
>read that paper from beginning to end, and inform your local community
>as to what you have learned.
>
>Ted Holden
>HTE

Actually, you should first find out who Alan Turing is, and how his name is
spelled. Then, after you read the paper by C.A.R. Hoare, you should read his
foreword to Watt, Wichmann, Findlay, "Ada Language and Methodology". Finally,
you should find out how Dr. Hoare feels about C and C++, so you have a context
to gauge what he says about Ada.

Rich Pattis





-- 
------------------------------------------------------------------------------
  Richard E. Pattis                     "Programming languages are like
  Department of Computer Science         pizzas - they come in only "too"
    and Engineering                      sizes: too big and too small."

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

[David Weller]

In article <314@fedfil.UUCP> news@fedfil.UUCP (news) writes:
>In article <1993Feb28.184206.27188@dragon.acadiau.ca>, 841613t@dragon.acadiau.ca (Don Tyzuk) writes:
> 
>> 
>> What I would like, is some suggestions on what I can do as a
>> 4th year CS student to educate my local community about Ada.
>
>You should start by finding out who Charles Anthony Richard Hoare is, and 
>what the ACM is, and what the Touring award is.  You should then find a
>copy of the lecture which Mr. Hoare delivered on the occasion of his
>receiving the Touring award from the ACM in 1980.  You should then
>read that paper from beginning to end, and inform your local community
>as to what you have learned.
>
>

You forgot to mention the blatent errors in CAR Hoare's presentation(which
was very negative of Ada).  

Don, the best thing to do is to contact your nearest SIGAda representative.
Give ACM a call and they will be more than glad to help you.  

>-- 
>Ted Holden
>HTE
>

Get a life, Ted.

dgw
---------------------------------------
my apologies to veteran c.l.a readers.  I usually don't reply to Ted's
rantings, but....

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

[Don Tyzuk]

news@fedfil.UUCP (news) writes:


>You should start by finding out who Charles Anthony Richard Hoare is, and 
>what the ACM is, and what the Touring award is.  You should then find a
>copy of the lecture which Mr. Hoare delivered on the occasion of his
>receiving the Touring award from the ACM in 1980.  You should then
>read that paper from beginning to end, and inform your local community
>as to what you have learned.

Dear Ted:

I have read Hoare's Turing award lecture, long prior to any interest
in Ada.  I would say then that I am not putting blinders on w.r.t.
the remarks in the lecture about Ada, because I formed my opinion
"pre-Ada".

I found Hoare's comments to be reactionary and un-substantiated.  I will
include them in my talk because I believe in presenting a balanced view.

Anyway, if one presents a one-sided argument full of rhetoric, it only
serves the purpose of the other side.

-- 
Don Tyzuk				| P.O. Box 1406
Jodrey School of Computer Science	| Wolfville, Nova Scotia
Acadia University			| CANADA     B0P 1X0
e-mail: don.tyzuk@acadiau.ca

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

[John Goodsen]

>In article <1993Feb25.170827.2178@ennews.eas.asu.edu> 
  stt@spock.camb.inmet.com (Tucker Taft) 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. ;-)
>

*often* but not *always*.  In the case of this news thread, the 
"hype" is not helping the perception of Ada 9X in a positive manner...


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

Actually, there's nothing saying that you can't have *MORE* than one
class per module (Ada package) in a class based language.  The class
supports the logical encapsulation of data and operations on that data
(which is the norm in the OO community).  Ada packages would provide
the capability to group related classes and nested classes.

What's the *real* problem with introducing the keyword "class"
instead of "type ... is tagged" ?!?!? 

The tagged type extension doesn't provide the logical encapsulation
mechanism for the associated operations.  So if I *do* add more
than one class (tagged type) to a package, where's the logical
encapsulation of the operations that can be performed on that type?
Leave it up to the programmer to place them in close proximity?
Add more rules to coding guidelines to ensure it?  I'd rather have
the language enforce it...

Is it really that painful to bite the bullet and add the keyword
"class" to the Ada language.  This simple addition to the current
9X approach will provide vendors such as us with a lot more
"perceptual power" to lobby the OO community to seriously look at
using Ada rather than languages such as C++ on their projects.
Once again I'll state it:  

   A *PERCEIVED* feature of an Object Oriented language is that
   it provides a class mechanism with polymorphic behavior.

If Ada 9X comes out without direct support for the concept of class,
then it will have trouble being *PERCEIVED* as a *real* OO language
and you can kiss all those new OO markets bye-bye.

It doesn't matter if I can *achieve* it with tagged types, the simple
fact of the matter is that most people won't dig deep enough into the
concept of tagged types to understand that this is where their
class/inheritance/polymorphism support is embedded.  They will end up
choosing languages like C++ which provide *direct* support for the
class concept.

What do we mean by *direct* support for the class concept?  Simple:

   Add the keyword "CLASS" to the language already !!!

Heck, you've already got the 'CLASS attribute in the language!  Is it
really that much more effort to use "CLASS" instead of 
"TYPE ... IS TAGGED" ???

I'm getting the feeling that the real reason for not adding CLASS to
the language is an extreeeeeeeeeme case of the "Not Invented Here"
syndrome.  In this case the NIH syndrome will hurt the marketing of
Ada as an OO language worse than anything else I can think of
(including the lack of direct support for multiple inheritance, which
is another issue :-)

>If you only declare one type 

   ... [talk about one type per module ]...

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

From reading the above, you can see that my vote is with Mr. Ichbiah...

>The MRT felt that it would simply further confuse the issue by trying
>to cloak our type extensions in the word "class."  
>

"Cloak" ?? Hmmm, so what you're saying is that Ada 9X truly doesn't
have a "class" concept but rather it is a "type extension" ?

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

How about a debate which includes $$ and cents in the marketing
of the language.  Too much technical focus and not enough
market focus on the OO support of Ada 9X will come back to haunt
us ...

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

 ... [ more talk about types inside modules ] ...

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

As the C++ market doubles each year, I don't think there is much
debate who the "winner" will likely be.  C++ has already layed out
most of commercial market battle field for OO languages in the next 10
years.  Wouldn't it be nice to say that "Ada has everything C++ has
*PLUS* tasking, hierarchical libraries, etc..."?  Ada 9X has got to
directly match the class concept of C++ or it will lose too many
potential users to a language which supports it.

When people read an OOD book and it talks about "classes",
"inheritance" and "polymorphism", they will naturally look for these
constructs in a language.  The majority of these people will bypass
Ada 9X when they see that it doesn't have direct support for "classes"
(unless this advice is heeded and the tagged types are changed to
classes :-)


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

All the more reason to allow multiple CLASSes in an Ada package?
(which tagged types gives us).  Now all we need to do is make them
look like a class instead of a "tagged type".  Then we've got the best
of both worlds! :-)

Leave Ada types and subtypes as they are in Ada 83.  They serve their
purpose just fine.  Don't confuse them with classes and inheritance.

>> . . .Should be an
>>interesting next few years.
>
>No debate there.
>

It would be even more interesting if Ada 9X became a *real*
commercial competitor of C++ !!!  

  CLASS!  CLASS!  CLASS!

If you don't have class, you won't be considered an OO language!!!
I doubt many reading this c.l.a newsgroup want to hear:

   "Ada's a nice language, but it doesn't have any CLASS!"

:-)



EDITOR'S NOTE: 

  There's more to changing "TYPE ... IS TAGGED" to "CLASS" than
  addressed in this post.  In particular the syntax and semantics of
  encapsulating functions/procedures within a class are left as
  excercise to the MRT. :-) Once again I'll point to Colin Atkinson's
  book on DRAGOON as an excellent example on how to do it...



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

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

[David Emery]

In my opinion, the term "class" is too tied up with C++ now.  I'ave
said many times that Ada's greatest strength is that it is *NOT*
C/C++.  Consider the average unwashed programmer who knows (or think
he knows C++).  When he sees the word "class", he will expect C++
class semantics.  If Ada9X does not deliver C++ semantics, then he'll
start screaming that Adas9X "got it wrong."  By not using the
boogie-word "class", we avoid bringing in all of the baggage now
associated with C++ classes.  

On the other hand, people who know multiple OO languages (e.g. Eiffel,
SmallTalk, Modula-3, etc.) will probably jnot be intimidated by the
absence of the "C-word".

We will not convince the died-in-the-wool (pun intended) programmer
who believes C is the greatest thing ever, and C++ is even better (is
this attitude consistent??), taht Adas9X offers a serious alternative.
In many respects, our big hope for Ada9X is for software engineers who
have tried C++ and don't like it, for whatever reason.  

				dave

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

[Tucker Taft]

In article <1993Mar7.191557.5547@evb.com> jgg@evb.com (John Goodsen) writes:

>>In article <1993Feb25.170827.2178@ennews.eas.asu.edu> 
>  stt@spock.camb.inmet.com (Tucker Taft) 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. ;-)
>>
>
>*often* but not *always*.  In the case of this news thread, the 
>"hype" is not helping the perception of Ada 9X in a positive manner...

Please note the "smiley."

> . . .
>What's the *real* problem with introducing the keyword "class"
>instead of "type ... is tagged" ?!?!? 
>
>The tagged type extension doesn't provide the logical encapsulation
>mechanism for the associated operations.  So if I *do* add more
>than one class (tagged type) to a package, where's the logical
>encapsulation of the operations that can be performed on that type?
>Leave it up to the programmer to place them in close proximity?
>Add more rules to coding guidelines to ensure it?  I'd rather have
>the language enforce it...

I can feel a religious war coming on...

In Ada 83, the package is the encapsulation/information-hiding construct.
Adding a keyword "class" to "type ... is tagged" wouldn't change
that at all, and the keyword substitution was all that Jean Ichbiah 
was proposing.  In fact, he specifically made it 
clear in his proposal that we should *not* change the encapsulation
rules.  After all, his team designed packages in the first place,
with full knowledge of the "class-based" alternatives present
in Simula-67, CLU, etc.

Using classes for encapsulation works great in some circumstances,
but breaks down in others.  If you are familiar with the
way operators work in C++, and the subtleties having to do
with implicit conversions on the "this" parameter versus the
other parameter (the "that" parameter ;-), the appropriate
use of "friends," etc., you begin to see the places where 
class=module approach breaks down.

Consider a typical definition of a "complex" abstract data type in 
Ada 83 (names of operations can be debated in e-mail):

   generic
       type Real is digits <>;
   package Complex_Numbers is
       type Complex is private;
       function "+"(L, R : Complex) return Complex;
       function "*"(L, R : Complex) return Complex;
     . . .
       function Cmplx(Re, Im : Real) return Complex;
       function Re(C : Compex) return Real;
       function Im(C : Compex) return Real;

       type Imaginary is private;
       i : constant Imaginary;   -- This allows "3.5 + 4.0*i" notation
       function "*"(L : Real; R : Imaginary) return Imaginary;
       function "*"(L : Imaginary; R : Real) return Imaginary;
       function "+"(L : Real; R : Imaginary) return Complex;
       function "+"(L : Imaginary; R : Real) return Complex;
     . . .
   private
       type Complex is record
         Re, Im : Real;
       end record;

       type Imaginary is new Real;
   end Complex_Numbers;

How would you write this in a "class-based" language?
At least in C++, operators almost always have to be made "friends"
to work right.  So much for language-enforced encapsulation.  And 
here we have two types, Complex and Imaginary, that are interrelated,
and are naturally defined in a single package.  One would
have to resort to "friends" or perhaps nesting in C++.

The C++ solution might nevertheless be quite elegant, if structured
properly according to reasonable coding guidelines, using the
file=module model where appropriate.  But in this case, we see
that Ada provides better direct encapsulation support than does
a class-based language.

So for some cases, where most operations have only a single
"interesting" parameter, the class-based approach seems more direct.
In other cases (like the above), the package-based approach
seems more direct and supportive of encapsulation.

In any case, Ada 83 clearly chose the package-based approach, and
we are not trying to change that for Ada 9X.  We felt that there
was no need to force Ada programmers to adopt a different way of
doing encapsulation just to get more support for dynamic binding 
and type extension.

We don't see the need to make Ada 9X a "me too" object-oriented
language.  Instead, we want it to combine the best ideas of
Ada 83 and OO languages, into something that advances the state
of the art, not something that trails just behind always trying 
to catch up.  We believe that this approach makes the most sense, 
both technical, and marketing.  Your mileage may of course vary...

> . . .
>John Goodsen
>EVB Software Engineering

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

[Michael Feldman]

In article <1993Mar8.153639.3603@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:
>
[ good stuff deleted]

>In any case, Ada 83 clearly chose the package-based approach, and
>we are not trying to change that for Ada 9X.  We felt that there
>was no need to force Ada programmers to adopt a different way of
>doing encapsulation just to get more support for dynamic binding 
>and type extension.
>
>We don't see the need to make Ada 9X a "me too" object-oriented
>language.  Instead, we want it to combine the best ideas of
>Ada 83 and OO languages, into something that advances the state
>of the art, not something that trails just behind always trying 
>to catch up.  We believe that this approach makes the most sense, 
>both technical, and marketing.  Your mileage may of course vary...
>
Hear, hear! It seems the same people who have trashed Ada for being too
stodgy and conservative now want Ada to be merely imitative of the latest
craze. Just because C++ does something in a certain way does NOT make
it the only way, or the only correct way. There is nothing to prevent
Ada from charting its own course. 

Ada's success will be fostered far more by the ready availability of
Ada9X compilers and tools at fair prices, including some free ones so
that we academics can muck around in the source code, than by whether
or not it uses the magic word "class". Instead of constantly kvetching
about classes vs. tagged types, let's get on about the _real_ business.
Freeze the language and get the compilers done.

I meet too many people who describe OOP as follows: "I don't know much
about it, but whatever it is, it's that stuff C++ can do and Ada can't."
It's high time to change this culture of ignorance. It starts in the
schools and works its way outward. The Ada83 "in group" missed this point.
Thank Heaven that the Ada9X "in group" seems (_seems_) to be getting it.
We shall see...

Cheers -

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"The most important thing is to be sincere, 
and once you've learned how to fake that, you've got it made." 
-- old show-business adage
------------------------------------------------------------------------

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

[Gregory Aharonian]

   With regards to the comments by Tucker and Mike, I think the original
emphasis of the posting is being overlooked.  Like it or not, Ada right now
is in a vicious competition with C++ and Smalltalk, and not doing very well.
Thus it seems to me that some purity will have to be sacrificed with
regards to Ada9X to achieve that level of commercial success necessary for
the DoD to achieve its original goals from Ada83 days.
   Looking at the people involved with Ada9X, there are very few people with
a business stake in the language (DoD types), or a great track record in
promoting Ada in the non-Mandated world (vendor types).  From the outside,
one could make the case that the Ada9X effort is doing its best to improve
the language while maintaining the status quo with regards to a language
that too many in the non-Mandated world can ignorantly, but easily, dismiss.

   I highly doubt that many on the Ada9X effort ever though the following
thought in any of their deliberations:  "If I was spending my own money on
this, what would I want".  From this point of view, the original posting's
call for more features in Ada9X that allows better competition with C++
(and Smalltalk) should be heeded.

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

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

[Tucker Taft]

In article <SRCTRAN.93Mar8171548@world.std.com> 
  srctran@world.std.com (Gregory Aharonian) writes:

> . . .
>   Looking at the people involved with Ada9X, there are very few people with
>a business stake in the language (DoD types), or a great track record in
>promoting Ada in the non-Mandated world (vendor types).  

This sentence is a bit hard to understand.  But my best guess of what
it means is quite far from the truth.  It seems that you have become
so frustrated with the Ada and DoD worlds that you have stopped talking
to anyone in those worlds.  That's fine, but then you should try to
refrain from generalizing about them.  Rest assured that *many* of the
people involved in Ada 9X have a *huge* stake in the language.  Some
of the best people involved work for small companies that are quite likely
to go belly-up if Ada 9X is a failure.  And those that work for
larger companies have a very large personal stake in the success of Ada 9X,
both economic and career-wise.

> . . . From the outside,
>one could make the case that the Ada9X effort is doing its best to improve
>the language while maintaining the status quo with regards to a language
>that too many in the non-Mandated world can ignorantly, but easily, dismiss.

You could make that case, I suppose, but you would almost 
certainly lose it, since the evidence to support it is incredibly
flimsy; the case on the opposite side is much stronger.

>   I highly doubt that many on the Ada9X effort ever though the following
>thought in any of their deliberations:  "If I was spending my own money on
>this, what would I want".  

You may "highly doubt" it, but I wonder on what basis you formed your opinion.
The truth is, in fact, just the opposite.  This question, at least,
I can answer with some authority ;-).  If we were spending our own money,
we would design Ada 9X the way we did design it.  And in any case,
like many people involved in computer science, spending our own money
is not nearly as painful as spending our own time and energy.
It is our express goal, and always has been, that Ada 9X will be the 
language of choice for systems programmers who have a choice.

> . . .From this point of view, the original posting's
>call for more features in Ada9X that allows better competition with C++
>(and Smalltalk) should be heeded.

There are many ways to skin a cat.  In many cases, imitation is not
the most effective strategy.  Why choose Ada 9X if it makes the same
mistakes that C++ does?  We should learn from the strengths and
weaknesses of other languages, and advance the state of the art, 
not solidify it around a 1985-vintage design.

Like others, I welcome your efforts to "wake up" the Ada community.
But you only serve to dilute your message by making unnecessary
generalizations based on lack of direct knowledge.  If you really
care, why not try to meet a few of the people involved with the Ada 9X
project?  If you don't, then don't dilute your message by making
unwarranted claims about us.

>Greg Aharonian

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

[C. Michael Holloway]

>>>>> On 9 Mar 93 14:20:13 GMT, stt@spock.camb.inmet.com (Tucker Taft) said:

tt> ...  If we were spending our own money, we would design Ada 9X the way we
tt> did design it.  And in any case, like many people involved in computer
tt> science, spending our own money is not nearly as painful as spending our
tt> own time and energy.  It is our express goal, and always has been, that
tt> Ada 9X will be the language of choice for systems programmers who have a
tt> choice.  ...  There are many ways to skin a cat.  In many cases,
tt> imitation is not the most effective strategy.  Why choose Ada 9X if it
tt> makes the same mistakes that C++ does?  We should learn from the
tt> strengths and weaknesses of other languages, and advance the state of the
tt> art, not solidify it around a 1985-vintage design.

From a purely technical point of view, I agree with this completely. 
Mr. Taft and the mapping/revision team have designed an excellent language --
one that I would choose for systems programming, were I to do such
programming and to have such a choice. 

Were technical factors the only factors that mattered, then Ada 9X would be a
resounding success; unfortunately, technical factors are rarely even the most
important ones.  We can all think of numerous examples of technically
inferior products that have become successes (to avoid offending someone,
I'll refrain from listing a few examples that come to my mind).

This is especially true in programming languages, because in many companies,
agencies, projects, etc, technically knowledgeable people are not the ones who
make the decisions as to what programming language will be used.  That's not
the way that things ought to be, but it is the way that things are in many
places. 

Personally, I am fully persuaded by Mr. Taft's arguments for the current
syntax and semantics of the object-oriented aspects of Ada 9X.  But that
syntax may well prevent the language from being used in many places; enough
places, I am afraid, to doom it to commercial failure.  In fact, if Mr. Taft
were to make these arguments to high level managers, the end of the
discussion might well resemble Paul's discussion with Festus in Acts 26 (to
paraphrase):

  Now as Mr. Taft thus made his defense, Mr. Manager said with a loud voice,
  "Tucker, you are beside yourself!  Much learning is driving you mad!"

  But he said, "I am not mad, most noble manager, but speak the words of
  truth and reason."

Now, Paul was discussing eternal truth and could not compromise his message,
but since Ada 9X is a little more temporal, some compromise ought to be
possible.

=================================================================
C. Michael Holloway             Email: c.m.holloway@LaRC.NASA.GOV
NASA Langley Research Center    Fax:   1 804 864 4234
Mail Stop 130                   Voice: 1 804 864 1701
Hampton VA 23681-0001 
--
=================================================================
C. Michael Holloway             Email: c.m.holloway@LaRC.NASA.GOV
NASA Langley Research Center    Fax:   1 804 864 4234
Mail Stop 130                   Voice: 1 804 864 1701
Hampton VA 23681-0001           Verse: Psalm 97:1

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

[Harry Koehnemann]

In article <SRCTRAN.93Mar8171548@world.std.com> srctran@world.std.com (Gregory Aharonian) writes:
>From this point of view, the original posting's
>call for more features in Ada9X that allows better competition with C++
>(and Smalltalk) should be heeded.

All I wanted to know was why type extensions were chosen over the
class construct (which I think Mr. Taft addressed).  I've always had
the question - Do classes or type extensions map better to typical OO
problems?  I've never seen any studys that compared the two.  I figured
that, since the OO additions were perhaps that largest change in a
rather costly revision process, someone might have looked into why
classes were so popular - maybe even done that study I've been looking
for.

Another point is that neither construct is new (despite what I hear on
c.l.a) and classes seem to have "won" in the OO world.  If Ada wants to
play ball in that community, I feel it's got a pretty big sell ahead of
itself - which could probably start with that study comparing classes
and type extensions for some model OO problems.  (kindof like doing the
feasibility study after the products built)

People seem to enjoy finding flaws in Ada.  Will type extensions be
another one of those problem areas people love to point at when talking
about Ada?  ("Type extensions!  We saw type extensions way back in...")
Either way, I think it's a big area of risk for 9X.
--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department

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

[Harry Koehnemann]

In article <1993Mar8.162831.8767@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>I meet too many people who describe OOP as follows: "I don't know much
>about it, but whatever it is, it's that stuff C++ can do and Ada can't."

Hmmm.  Most the OO people I know talk about OO as "objects, classes,
and inheritance" and discuss objects as active entities (rather than
passive as they are with tagged types).  I don't mean to downplay the
work done on 9X and I personally haven't resolved the "Classes vs. Type
Extensions" question yet, but these are likely arguments you're going to
get from the OO community.

Every OO text I know of defines an OO language as Objects, Classes, and
Inheritance.  Granted type extensions yield a form of classification,
but it is not as evident as it is in a language with a construct called
"class".  And, we have yet to determined whether that form of
classification is as useful as a class.

Second, OO principles are very big on objects being active.  I write
Obj.Operation rather than Operation(Obj).  In fact, people have
hinted at Ada83 being OO because of the tasking mechanism, simply
because it uses hte proper notation (and that tasks have an internal
thread of control).  How does my OO design translate into a language
where objects aren't active?

>It's high time to change this culture of ignorance. It starts in the
>schools and works its way outward. The Ada83 "in group" missed this point.
>Thank Heaven that the Ada9X "in group" seems (_seems_) to be getting it.
>We shall see...

I agree completely.  If you're going to sell Ada as object-oriented,
you'd better be prepared to defend that statment.  I disagree with
your assessment of the OO community.  Most of them really know their
shit when it comes to OOness and we sure as hell don't want to loose
arguments because we are ignorant of the facts.  I'm just getting
prepared for what's likely ahead.

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

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

[Tom Wicklund]

In <1993Mar8.153639.3603@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:

>I can feel a religious war coming on...

I don't want to start a religious war, but I think Mr. Taft's
experience with C++ is too limited.  On the other hand, I've never
done any real Ada programming so I apologize in advance for any errors
in my knowledge of Ada.

Both C++ and Ada have their strengths and weaknesses, I'm not fond of
either as a "favorite" langauge though I have some preference for C++
due primarily to better familiarity.

>Using classes for encapsulation works great in some circumstances,
>but breaks down in others.  If you are familiar with the
>way operators work in C++, and the subtleties having to do
>with implicit conversions on the "this" parameter versus the
>other parameter (the "that" parameter ;-), the appropriate
>use of "friends," etc., you begin to see the places where 
>class=module approach breaks down.

However, C++ doesn't use a class=module approach.  You're comment
applies more to a language like Eiffel.  C++ uses the class to control
information hiding, similar to (one function of) Ada's package.

>Consider a typical definition of a "complex" abstract data type in 
>Ada 83 (names of operations can be debated in e-mail):

>   generic
>       type Real is digits <>;
>   package Complex_Numbers is
>       type Complex is private;
>       function "+"(L, R : Complex) return Complex;
>       function "*"(L, R : Complex) return Complex;
>     . . .
>       function Cmplx(Re, Im : Real) return Complex;
>       function Re(C : Compex) return Real;
>       function Im(C : Compex) return Real;

>       type Imaginary is private;
>       i : constant Imaginary;   -- This allows "3.5 + 4.0*i" notation
>       function "*"(L : Real; R : Imaginary) return Imaginary;
>       function "*"(L : Imaginary; R : Real) return Imaginary;
>       function "+"(L : Real; R : Imaginary) return Complex;
>       function "+"(L : Imaginary; R : Real) return Complex;
>     . . .
>   private
>       type Complex is record
>         Re, Im : Real;
>       end record;

>       type Imaginary is new Real;
>   end Complex_Numbers;

>How would you write this in a "class-based" language?
>At least in C++, operators almost always have to be made "friends"
>to work right.

No they don't.  I suggest you look at the GNU g++ library
implementation of complex, which I summarize below.  Note that there
are NO friend functions.  There are differences, reflecting the
differences between Ada's and C++'s approaches to types and
differences in the approach to the implementation.

On the other hand, Ada packages are analagous to providing a "friend"
declaration between all types declared in the package.  If "friends
are so bad, then Complex and Imaginary should be in different packages
so they can't get at each other's internals (which is basically what a
C++ friend declaration does).

NOTE:  I've edited the following somewhat to remove inline function
implementations and several of the operations.

/* 
Copyright (C) 1988 Free Software Foundation
    written by Doug Lea (dl@rocky.oswego.edu)

This file is part of GNU CC.
*/

class Complex
{
protected:			// analagous to Ada's private part
  double           re;
  double           im;

public:
  inline double real() const;	// get real part of number
  inline double imag() const;	// get imaginary part of number

  // Create a complex number
  inline           Complex();
  inline           Complex(const Complex& y);
  inline           Complex(double r, double i=0);

  // assignment
  inline Complex&  operator =  (const Complex& y);

  // Basic operations (add to number, subtract from number, etc).
  inline Complex&  operator += (const Complex& y);
  inline Complex&  operator += (double y);
  inline Complex&  operator -= (const Complex& y);
  inline Complex&  operator -= (double y);
  inline Complex&  operator *= (const Complex& y);
  inline Complex&  operator *= (double y);

  Complex&         operator /= (const Complex& y); 
  Complex&         operator /= (double y); 
};

// Other operations on Complex.  No friend functions needed.

// Comparison operations.
int operator == (const Complex& x, const Complex& y);
int operator == (const Complex& x, double y);

int operator != (const Complex& x, const Complex& y);
int operator != (const Complex& x, double y);

Complex operator - (const Complex& x);	  // negation
Complex conj(const Complex& x);		  // conjugate

// Arithmetic:
Complex operator + (const Complex& x, const Complex& y);
Complex operator + (const Complex& x, double y);
Complex operator + (double x, const Complex& y);

Complex operator - (const Complex& x, const Complex& y);
Complex operator - (const Complex& x, double y);
Complex operator - (double x, const Complex& y);

// Similarly for *, /.

// More complicated operations:

Complex polar(double r, double t = 0.0);
Complex cos(const Complex& x);
Complex sin(const Complex& x);

// (removed abs, norm, arg, sinh, cosh, exp, log, pow (power), sqrt).


>  So much for language-enforced encapsulation.  And 
>here we have two types, Complex and Imaginary, that are interrelated,
>and are naturally defined in a single package.  One would
>have to resort to "friends" or perhaps nesting in C++.

I'm sure a C++ example could be created with classes Real, Imaginary,
and Complex.

There are also things which a C++ version could do and Ada can't.  For
instance, I don't think your Ada version as specified above allows
assignment between types, in particular, how do I assign an imaginary
value to a complex?

Complex := Imaginary;		   -- type violation.
Complex := Cmplx(Real, Imaginary); -- defined as Cmplx(Real, Real)
Complex := (0, Imaginary);	   -- private type.

I assume I have to get the package implementor to write a new function:

function Cmplx(re: Real; Im: Imaginary) return Complex;

Or alternately something like:

Complex := Cmplx(Re, Real(Im));	   -- use explicit conversion.
	   `			   -- can I do this to generics?

>The C++ solution might nevertheless be quite elegant, if structured
>properly according to reasonable coding guidelines, using the
>file=module model where appropriate.  But in this case, we see
>that Ada provides better direct encapsulation support than does
>a class-based language.

And one could write a very poorly structured Ada implementation which
violates package structures.  You may have some protection above
because the package is generic, I'm not familiar enough with Ada
generics.

I do agree that it's easier to create poorly packaged code in C++ than
in Ada.  From that standpoint Ada provides better encapsulation, but
it's by no means ideal.

There is also a problem discussed extensively in the Ada 9X materials
about how to handle mixing operations of types Matrix and Vector, so
Ada's encapsulation has it's problems also (this particular problem
isn't easy in either class based languages like Eiffel or in C++
either, though solutions can be done in any of these langauges).

>In any case, Ada 83 clearly chose the package-based approach, and
>we are not trying to change that for Ada 9X.  We felt that there
>was no need to force Ada programmers to adopt a different way of
>doing encapsulation just to get more support for dynamic binding 
>and type extension.

Regardless of the above, you're right to maintain Ada's encapsulation
philosophy.  I don't like Ada's approach as much as some others, but
there's nothing inherently wrong with it.

>We don't see the need to make Ada 9X a "me too" object-oriented
>language.  Instead, we want it to combine the best ideas of
>Ada 83 and OO languages, into something that advances the state
>of the art, not something that trails just behind always trying 
>to catch up.  We believe that this approach makes the most sense, 
>both technical, and marketing.  Your mileage may of course vary...

True, though I'm not sure Ada 9X is advancing the state of the art
past other languages (personal opinion).

>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

[Larry M. Jordan]

I must agree with the recent posts that express concern over
Ada 9X's OOP features not be recognized as such.  I'm not an 
'average' programmer (I know Ada, C++, Turbo Pascal, a number 
of Modula-2s with OOP, Oberon-2).  Yet, I had no little difficulty 
reading the Ada 9X rationale and understanding just how 9X will 
support OOP.

I think introducing the keyword 'tagged' is a mistake.  It sure
didn't facilitate my understanding.  It wasn't until I read
the paper by Dismukes and Rome that I realized, 'Oh, this
isn't so different after all.'  My impression (and it may be only
mine) is that 'tagged' is an implementation detail that has
somehow leaked out.  What an ugly word it is (and how many times 
will it be misspelled!--one 'g' or two?).  Ichbiah's suggestion
seems preferable.

There will probably be better sources for learning Ada 9X OOP
features (there probably are now).  But at the time, the rationale was
all I had.  Maybe a book/monograph needs to be written that's palatable
to the pop programming culture, speaking to them at their level, an
'Ada 9X Primer'?!  Until there is, I'm afraid that Ada 9X OOP
will be preceived as something 'unfamiliar'.

--Larry

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

[Larry M. Jordan]

In article <SRCTRAN.93Mar8171548@world.std.com> srctran@world.std.com (Gregory Aharonian) writes:
>   With regards to the comments by Tucker and Mike, I think the original
>emphasis of the posting is being overlooked.  Like it or not, Ada right now
>is in a vicious competition with C++ and Smalltalk, and not doing very well.

[lots of excellent stuff deleted]

>
>this, what would I want".  From this point of view, the original posting's
>call for more features in Ada9X that allows better competition with C++
>(and Smalltalk) should be heeded.
>

Let me register my agreement with Greg.  I'd sure like to know how
many others feel this way. 

--Larry

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

[David Weller]

In article <1nip3kINNb2c@news.aero.org> jordan@aero.org (Larry M. Jordan) writes:
>I must agree with the recent posts that express concern over
>Ada 9X's OOP features not be recognized as such.  I'm not an 
>'average' programmer (I know Ada, C++, Turbo Pascal, a number 
>of Modula-2s with OOP, Oberon-2).  Yet, I had no little difficulty 
>reading the Ada 9X rationale and understanding just how 9X will 
>support OOP.
>

Indeed, it IS a nontrivial document aimed at the Ada fluent (and
C++/CLOS/Smalltalk fluent, to a degree).  I'm not so sure this 
makes it a Bad Thing.  There has been considerable discussion
about simplifying the Rationale (right, Tuck?).

>I think introducing the keyword 'tagged' is a mistake.  It sure
>didn't facilitate my understanding.  It wasn't until I read
>the paper by Dismukes and Rome that I realized, 'Oh, this
>isn't so different after all.'  My impression (and it may be only
>mine) is that 'tagged' is an implementation detail that has
>somehow leaked out.  What an ugly word it is (and how many times 
>will it be misspelled!--one 'g' or two?).  Ichbiah's suggestion
>seems preferable.
>

Yeah, and I've lost count of how many Ada programmers I've taught
that can't spell seperate(sic) :-)

Tucker would be quick to point out that the word "record" is also
an implementation detail, but that it's become generally accepted
in the programming domain.  Frankly, I don't care for the word
"tagged" either, but "class" doesn't fit in its place.  Do you 
have an alternate suggestion?

One other thing that's bothered me -- why are we raising such a fuss
about the word "tagged" to mean "this record may have it's state
description extended"?  Perhaps we're being pedantic?  Where were 
such arguments when the "C" language reference said "*" means
"pointer"?  :-)   (Smiley for the humor impaired)

>There will probably be better sources for learning Ada 9X OOP
>features (there probably are now).  But at the time, the rationale was
>all I had.  Maybe a book/monograph needs to be written that's palatable
>to the pop programming culture, speaking to them at their level, an
>'Ada 9X Primer'?!  Until there is, I'm afraid that Ada 9X OOP
>will be preceived as something 'unfamiliar'.
>

If you'll look in the Ada 9X Project Plan (whatever), you'll
see there's TWO 9X primers: one for the Ada literate and one for
the "Real Language" impaired :-)  I believe there's also a
plan for video tapes (hopefully it will be a little more lively
than the ones Alsys sold back in the mid 80's).  I'm not sure
of the release dates for the primers, but I'm sure it won't be before
the ANSI acceptance of 9X.

>--Larry
>

dgw

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

[Michael Feldman]

In article <1993Mar9.171230.28664@ennews.eas.asu.edu> koehnema@enuxhb.eas.asu.edu (Harry Koehnemann) writes:
>
>All I wanted to know was why type extensions were chosen over the
>class construct (which I think Mr. Taft addressed).  I've always had
>the question - Do classes or type extensions map better to typical OO
>problems?  I've never seen any studys that compared the two.  I figured

Ummm - you might start with Rosen's article in Nov. 92 Comm. ACM.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"The most important thing is to be sincere, 
and once you've learned how to fake that, you've got it made." 
-- old show-business adage
------------------------------------------------------------------------

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

[Michael Feldman]

In article <1993Mar9.174925.29392@ennews.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) writes:
>In article <1993Mar8.162831.8767@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>>I meet too many people who describe OOP as follows: "I don't know much
>>about it, but whatever it is, it's that stuff C++ can do and Ada can't."
>
>Hmmm.  Most the OO people I know talk about OO as "objects, classes,
>and inheritance" and discuss objects as active entities (rather than
>passive as they are with tagged types).  I don't mean to downplay the
>work done on 9X and I personally haven't resolved the "Classes vs. Type
>Extensions" question yet, but these are likely arguments you're going to
>get from the OO community.

Oh, you and I are tekkies. I mean the project managers, the ones who get
to make the decisions. Some of them even have gold braid on their starched
shirts.
>
>Every OO text I know of defines an OO language as Objects, Classes, and
>Inheritance.  Granted type extensions yield a form of classification,
>but it is not as evident as it is in a language with a construct called
>"class".  And, we have yet to determined whether that form of
>classification is as useful as a class.

Correct. 'Course the OO texts have picked up on a recent bit of jargon.
They may not have a monopoly on truth; they've just co-opted the buzzwords.
>
>Second, OO principles are very big on objects being active.  I write
>Obj.Operation rather than Operation(Obj).  In fact, people have
>hinted at Ada83 being OO because of the tasking mechanism, simply
>because it uses hte proper notation (and that tasks have an internal
>thread of control).  How does my OO design translate into a language
>where objects aren't active?

You are obviously not in the category of folks I was referring to.
>
>>It's high time to change this culture of ignorance. It starts in the
>>schools and works its way outward. The Ada83 "in group" missed this point.
>>Thank Heaven that the Ada9X "in group" seems (_seems_) to be getting it.
>>We shall see...
>
>I agree completely.  If you're going to sell Ada as object-oriented,
>you'd better be prepared to defend that statment.  I disagree with
>your assessment of the OO community.  Most of them really know their
>shit when it comes to OOness and we sure as hell don't want to loose
>arguments because we are ignorant of the facts.  I'm just getting
>prepared for what's likely ahead.
>
The folks I mean are not in "the OO community." I meant what I said QUITE
LITERALLY: they know little about OO but somebody, somewhere, told them
that C++ could do it and Ada couldn't. They haven't got the foggiest idea
whether Objects, Classes, Inheritance, etc., would make a damn bit of 
difference in the cost-effectveness of their project. But somebody told
'em that OO was the greatest thing since sliced bread, reason enough
to fight the Ada Mandate. Arrant nonsense. But it's out there. It's
enough to make your hair stand on end. And it's your tax money and mine.

Mike

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

[Michael Feldman]

In article <1993Mar9.152454.739@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (David Weller) writes:
>
>If you'll look in the Ada 9X Project Plan (whatever), you'll
>see there's TWO 9X primers: one for the Ada literate and one for
>the "Real Language" impaired :-)  I believe there's also a
>plan for video tapes (hopefully it will be a little more lively
>than the ones Alsys sold back in the mid 80's).  I'm not sure
>of the release dates for the primers, but I'm sure it won't be before
>the ANSI acceptance of 9X.
>
Ummm - anyone know who's writing it?

Mike

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

[Gregory Aharonian]

>This sentence is a bit hard to understand.  But my best guess of what
>it means is quite far from the truth.  It seems that you have become
>so frustrated with the Ada and DoD worlds that you have stopped talking
>to anyone in those worlds.  That's fine, but then you should try to
>refrain from generalizing about them.  Rest assured that *many* of the
>people involved in Ada 9X have a *huge* stake in the language.  Some
>of the best people involved work for small companies that are quite likely
>to go belly-up if Ada 9X is a failure.  And those that work for
>larger companies have a very large personal stake in the success of Ada 9X,
>both economic and career-wise.

Tucker,
	Let me make it easier to understand.  Consider the general trade
press in computing, with such publications as Computerworld, Software,
Datamation, Mid-Range Systems, Computer Language, Infoworld, Open Systems
Today, Computer Design, the IEEE and ACM general publications, Data
Management Review, and others.	I rarely, if ever, see any ads for Ada
compilers from most of the companies reflected in the Ada9X effort.  Nothing.
  	Consider the general (by general, I mean non-Mandated) trade shows.
Object World, CASE World, Software Engineering XX, etc.  Rarely, if ever,
do I see much of an Ada presence by most of the companies reflected in the
Ada9X effort.
	Sure, I believe that you guys have a "huge" stake in the Ada9X
effort, but based on this behavior analysis, it seems that the stake you
are striving for is the nice cozy Mandated world.  I do not see much
evidence that you guys are taking the evangelizing of Ada seriously,
outside the Mandated world.  I rarely if ever see ads for Ada, trade
show booths for Ada, bingo cards in card decks for Ada, direct mail
pieces for Ada, anything for Ada.
 	I just don't see anything being done to better promote Ada.
Nothing from the DoD, nothing from DoD contractors, and especially nothing
from Ada compiler vendors.  You tell me where are the continually running
ads for Intermetrics, Alsys, Meridian, Verdix, Aetech, etc.  Scattershot
is what I see at best, especially compared to the advertising square inch
space for other languages.

	Thus Tucker, my original concern still holds.  I barely see any
presence of many of the Ada9X people in the non-Mandated world, and am
afraid that what will come out of the Ada9X effort will be a great
language that will be even less accepted in the non-Mandated world than
Ada83.

	Prove me wrong that there you guys have a much bigger presence
in the non-Mandated world. If nothing else, explain to me why Intermetrics
(at least in Cambridge) seems to keep on losing its best programmers
(many of whom are my friends) to numerous C/C++ efforts in the Boston area.

	If nothing else, how about a round of golf at Fresh Pond to
settle this one way or the other.  If you win, I'll admit that Ada has
behind it the best marketing campaign in advertising history, and if I
win, you'll admit that you are all a bunch of parasites (in the strictly
biological analogy meaning).

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

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

[John Goodsen]

stt@spock.camb.inmet.com (Tucker Taft) writes:

>srctran@world.std.com (Gregory Aharonian) writes:
>> . . .From this point of view, the original posting's
>>call for more features in Ada9X that allows better competition with C++
>>(and Smalltalk) should be heeded.
>
>There are many ways to skin a cat.  In many cases, imitation is not
>the most effective strategy.  Why choose Ada 9X if it makes the same
>mistakes that C++ does?  

Which is hardly what I was proposing.  Are you saying that classes
are a mistake in C++ ?  I would hope that the real message of 
the original posting was received as:

  Object Oriented Analysis and Design approaches (most of them
  and certainly the mainstream) use class based approaches.  
  When a software engineer performs OOA and/or OOD, it is going
  to be quite natural to look for an implementation language
  which *has class*.  If you don't make it easy for someone on
  the language search to see that Ada supports the concept of
  "class", then the acceptance of the language for OO development
  will not meet it's true potential.

I have heard the arguments on why tagged types are *better* than
classes, and for the most part agree with them.  This is not a
technical issue.  It's a market acceptance issue.  If the solution
is to change the syntax from "tagged type" to "class" and leave
it at that, then it doesn't sound like too much of a problem and
I will predict that the commercial payoff will be worth the minor
syntactical change.  

I know what you're thinking:  "But, if we change 'tagged type'
syntax to 'class' syntax, it won't be a class in the same
terms as other languages!"  Great!  If you want to introduce the
world to a better object oriented programming mechanism, then
at least speak to the world in their language.  The language
that people will understand is "class", not "tagged type".

A class in CLOS, smalltalk and C++ are not identical already.
The argument that if Ada uses the word "class" then it has
to be exactly like C++'s implementation of a class doesn't
hold water.  Don't let a C++ vs. Ada bias affect this "CLASS"
syntax issue.  It will seriously hinder new market acceptance of
Ada as an OOP language.

>
>We should learn from the strengths and
>weaknesses of other languages, and advance the state of the art, 
>not solidify it around a 1985-vintage design.
>

So is it safe to assume that 9x tagged types are considered
as "advancing the state of the art" by the Ada 9X project or
wasn't the syntax terminology introduced to remain consistent
with the Ada 83 "state of the art".

A serious question, really :-)

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

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

[John Goodsen]

wellerd@ajpo.sei.cmu.edu (David Weller) writes:

>Tucker would be quick to point out that the word "record" is also
>an implementation detail, but that it's become generally accepted
>in the programming domain.  

This is irrelevant to the class vs. tagged type discussion.
Or is it?  "class" is generally accepted in the OO programming
domain.  Tagged Type ?  really not even known in the OO programming
domain.


>Frankly, I don't care for the word
>"tagged" either, but "class" doesn't fit in its place.  
>
By what measurement?  C++ syntax? Again, if you want to make
an impact against markets like the C++ market, you need to at
least speak the language.  Change the semantics for
technical superiority, but you'll never get the OO message out
using terminology that the OO community doesn't (for the most
part) understand, namely "tagged types".  



>One other thing that's bothered me -- why are we raising such a fuss
>about the word "tagged" to mean "this record may have it's state
>description extended"?  Perhaps we're being pedantic?  

The whole argument for class vs. tagged type is based solely upon
the need for Ada 9X to gain support as an OO language.  This is
not pedantic.  It is realistic awareness of the programming community
and how to grow a business centered on Ada technology.


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

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

[David Emery]

>A class in CLOS, smalltalk and C++ are not identical already.
>The argument that if Ada uses the word "class" then it has
>to be exactly like C++'s implementation of a class doesn't
>hold water. 

What percentage of practicing C++ programmers know CLOS and/or
SmallTalk?  My experience (direct and indirect, including the several
places my wife has worked recently) is "few".  Sure, there are people
who know multiple languages.  In this case, Ada's tagged types would
also be a reasonable concept (akin to Modula-3).  But, for the great
masses of C++ programmers, the word "class" means "C++ class", and I
believe their reaction is "different is wrong".
				dave

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

[Tucker Taft]

In article <1993Mar9.181231.27197@intellistor.com> 
  wicklund@intellistor.com (Tom Wicklund) writes:

>>How would you write this in a "class-based" language?
>>At least in C++, operators almost always have to be made "friends"
>>to work right.
>
>No they don't.  I suggest you look at the GNU g++ library
>implementation of complex, which I summarize below.  Note that there
>are NO friend functions.  

Thanks for pointing this out.  What I should have said
was that operators must generally *not* be member functions
if they are going to work right in conjunction with
implicit conversions.  As you illustrate, if the functionaliy
of a non-member-function operator can be expressed in terms
of some member function (operator or otherwise), then there
is no need to make the non-member-function operator a "friend."

Your example, however, illustrates the point I was *trying* (albeit
ineffectively ;-) to make, that the "encapsulation" provided
by a C++ class construct is not always complete, since one must revert
to non-member-function declarations (for example for many binary
operators) to get the desired functionality.  This is neither
good nor bad as far as I am concerned.  It just shows that a
"religious" belief that "class-based" languages (in as much
as C++ is one) do a better job of encapsulating all of the 
interesting operations "inside" the class, doesn't always 
turn out to be true.  However, by using files as modules, one
can get the logical grouping you desire in C++.

In Ada, the package provides all encapsulation, both for
the equivalent of member functions ("primitive subprograms" in
Ada 9X, "derivable subprograms" in Ada 83) and for any
associated types, operators, exceptions, generics, etc.
Either way works, but having *both* a class-based encapsulation
and a package-based encapsulation in a single language would
almost certainly result in undesirable complexity and confusion.

As far as the great "class" vs. "tagged" debate, Ada 9X does
have classes, and in fact the word "Class" appears quite prominently
in any Ada 9X example that uses polymorphism.  It just doesn't
happen to appear in the declaration of a tagged type.
Instead it appears in the declaration of polymorphic operations
and access types.  The concept of "class" is also behind the scenes 
any time you define a generic with a formal type 
like "type I is range <>;" since any type in the integer "class"
matches such a declaration (this is an example of compile-time
polymorphism).

As far as marketing to the masses, the big term these days 
is "object technology" not "class-based languages."
Given that, we should presume that Modula-3, since it uses
the term "object" in its syntax for OOP-related types, should
soon take over the world!  

One last note, before I retire from this debate, for the history buffs
who like to quote the computer science greats...

  One of the earlier places where the term "tag" appears in scholarly
  circles is in the classic book "Structured Programming" by
  O.-J. Dahl, E. W. Dijkstra, and C. A. R. Hoare.
  In Hoare's chapter entitled "Notes on Data Structuring,"
  in the section on "The Discriminated Union" he begins
  his subsection on "Manipulation" as follows:

     Any value of a discriminated union carries with it a "tag"
     field indicating which of the particular constituent types it
     originated from; on assignment this is copied, and on a test
     of equality, the tag fields must be the same if the values
     are to be equal.

  Hoare and Niklaus Wirth collaborated somewhat on the development
  of this concept, and "tag" was the term Wirth adopted in his
  description of Pascal (e.g. in the Pascal User Manual and Report).

  The term "tag" is also used in more recent "scholarly" contexts, 
  particularly in a paper on "Dynamic Typing in a Statically Typed 
  Language" by Abadi, Cardelli, Pierce, and Plotkin (TOPLAS 4/91).

Probably the major objection to the term "tagged" is that
it *sounds* too low-level and implementation oriented.  Of course,
some might find that comforting in a systems-programming language.
But even for those who prefer abstractness in a language, the
term "tagged" really just means "self-identifying."
Each "tagged" object in Ada 9X identifies its own underlying type.  
This is the key to run-time polymorphism, and is the critical step from
an abstraction-oriented language like Ada 83, to an "object"-oriented
language like Ada 9X.  In Ada 83, a given abstraction interface
has exactly one implementation.  In Ada 9X, as in other OOP languages,
a given interface may have many implementations, typically organized
into some kind of hierarchy.  The objects carry around an identifying
(abstract ;-) tag that allows them all to be manipulated through
a common interface, but still nevertheless to be treated specially
according to their self-identifying tag when appropriate, through
the "magic" of run-time dispatching.  Ada 83 already had abstract
data types (unlike C); they were called "private types."  In Ada 9X,
abstract data types are still called private types.  However, if
you want to use them with run-time polymorphism, then they have
to be "tagged" private types.  But they are still "private" types, 
and in many cases that is more fundamental than the fact
that they are "tagged."

So that's the technical/computer-science justification for the term.
As far as marketing, we do use the term "class" heavily in Ada 9X,
and we use it in a way that meshes nicely with its use in other
OO languages.  However, we made a judgement call that to use
it in the *syntax* of tagged types, and to call such types
"class types" would result in more problems (marketing and technical)
than it solved.

This judgement call was based on technical merit, on
marketing considerations, on usability, etc.  Of course, others
might reach a different conclusion (of course, others *have* reached
a different conclusion ;-).  Such is the way with language design.
You have to make some tough, but in many ways, "arbitrary" choices,
using the clearest "crystal ball" you can devise, and with an
eye toward the overall consistency and aesthetics of the language --
it is unwise to try to make one "corner" of the language "beautiful"
at the expense of overall consistency and usability.

In any case, it is quite unlikely that you will please everyone with
every design choice.  It is quite likely that there will be some vocal,
heartfelt, and well justified arguments on the opposite side of
almost every decision.  This particular choice seems to be
one of the "canonical" examples of that phenomenon.

But at some point, you make a decision and move on.  In this area,
we have done that, and only posterity will be able to confirm
whose "crystal ball" was clearer.  The only thing worth reiterating,
is that even if you don't agree with our decision, please believe
that we have the same technical, usability, and marketing concerns
as everyone who hopes that Ada 9X will be a widely-used, highly
productive programming language for developing and maintaining
the complex software systems of the 90's and beyond.

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

[Tucker Taft]

In article <1993Mar9.210350.14567@seas.gwu.edu> 
  mfeldman@seas.gwu.edu (Michael Feldman) writes:

>In article <1993Mar9.152454.739@sei.cmu.edu> 
>  wellerd@ajpo.sei.cmu.edu (David Weller) writes:
>>
>>If you'll look in the Ada 9X Project Plan (whatever), you'll
>>see there's TWO 9X primers: one for the Ada literate and one for
>>the "Real Language" impaired :-)  I believe there's also a
>>plan for video tapes (hopefully it will be a little more lively
>>than the ones Alsys sold back in the mid 80's).  I'm not sure
>>of the release dates for the primers, but I'm sure it won't be before
>>the ANSI acceptance of 9X.
>>
>Ummm - anyone know who's writing it?

John Barnes is working on the 9X Rationale these days,
with help from other members of the Mapping/Revision Team.  
Some version of the rationale will accompany the documents
circulated for ANSI Canvass/ISO balloting.

Several video tapes will be produced, some (short) "glossy" ones
for CEOs, CIOs, chief technical officers, etc., and some (longer) 
"pragmatic" ones for programmers, both Ada 83 and C/C++ types.
These will probably not be ready until after the balloting
process is nearly complete.

>Mike

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

[Tom Pole]

In article <EMERY.93Mar10174143@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery) writes:
>>A class in CLOS, smalltalk and C++ are not identical already.
>>The argument that if Ada uses the word "class" then it has
>>to be exactly like C++'s implementation of a class doesn't
>>hold water. 
>
>What percentage of practicing C++ programmers know CLOS and/or
>SmallTalk?  My experience (direct and indirect, including the several
>places my wife has worked recently) is "few".  Sure, there are people
>who know multiple languages.  In this case, Ada's tagged types would
>also be a reasonable concept (akin to Modula-3).  But, for the great
>masses of C++ programmers, the word "class" means "C++ class", and I
>believe their reaction is "different is wrong".
>				dave

I have enjoyed this battle up to this point, without participating.
Now I can't resist the comment. Who Cares (only) what the average C++
programmer thinks. (In this discussion, not in all matters, I have
nothing against C++ programmers, some of my best friends are... etc.)
C++ is not the only OOPL used in software development, nor will it
ever be. If Ada disappears tomorrow (DOD forbid), there will still
be serious development done in Smalltalk, Eiffel, and CLOS.
If Ada is to break into the commercial OOPL market in more than
a token way, it must present the OO programmer with an OOPL, not
just try to compete with C++. Most OO programmers have mutual
respect for each other's favorite languages, AND have a common
shop-talk language to discuss the compartive benefits of each.
This shop-talk includes class, but not tagged types.

If Ada wants to attract/convince/whatever programmers to use Ada, and 
that it is truly an OOPL, then Ada should use the accepted (de facto standard)
terminology of OORequirements Analysis, OODesign, OOetc.

A class is a class. If Ada wants to add the ability to have 
inheritance/specialization similar to what is available in other
OOPL's, the OO world calls the common definition
of a type which supports specialization a class, and instantiations
of that type objects. Ada can use the same terms if it wishes.

If Ada wants to add the ability to have specialization
but keep it a secret that only Ada initiates understand, then
call it some obscure, uncommon, semantically weak term like tagged
types. There is not a theasaurus in the world that is going to relate
any of the terms class, inhertance, inheritable type, specialization,
or object oriented with the word tagged.

The only other software related use of tagged types I know of refers to 
the tagged types implemented in hardware for Lisp machines. Haven't
heard that term used lately.

Thomas Pole
All opinions are my own, unless I can find someone else
to blame them on.
-- 

Thomas Pole

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

[Anthony Howell]

In article <EMERY.93Mar10174143@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery) writes:
>
>What percentage of practicing C++ programmers know CLOS and/or
>SmallTalk?  My experience (direct and indirect, including the several
>places my wife has worked recently) is "few".  Sure, there are people
>				dave

Just to let you know, I teach Smalltalk programming in our company (Hughes Aircraft) to
help the people make the paradigm shift to OOT and then we teach them C++ for the
real stuff in our area.  (True there are ADA 9X advocates here, but I am not one of them.)

Tony Howell

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

[Charles H. Sampson]

In article <1993Mar12.160136.6106@evb.com> pole@evb.com (Tom Pole) writes:

>If Ada is to break into the commercial OOPL market in more than
>a token way, it must present the OO programmer with an OOPL, not
>just try to compete with C++. Most OO programmers have mutual
>respect for each other's favorite languages, AND have a common
>shop-talk language to discuss the compartive benefits of each.
>This shop-talk includes class, but not tagged types.
>
> ...
>
>A class is a class. If Ada wants to add the ability to have 
>inheritance/specialization similar to what is available in other
>OOPL's, the OO world calls the common definition
>of a type which supports specialization a class, and instantiations
>of that type objects. Ada can use the same terms if it wishes.

     What about that part of the published OO world that uses the terms
object and instance for those concepts?  The point of that rhetorical
question is, of course, OO terminology is far from fixed.  If the 9X
boys can come up with a better term, particularly if they're trying to
make it clear that the thing they've defined is not the same as the C++
thing, good for them.

     That said, I have a lot of trouble with tagged.  It's just a long-
held belief of mine that a language feature shouldn't even appear to be
suggesting its implementation.

				Charlie

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

[Michael Feldman]

In article <1993Mar12.144940.18386@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:

[stuff deleted]
>
>John Barnes is working on the 9X Rationale these days,
>with help from other members of the Mapping/Revision Team.  
>Some version of the rationale will accompany the documents
>circulated for ANSI Canvass/ISO balloting.
>
A Rationale is fine, but the original question asked about the promise
of _primers_ written to _teach_ 9X. This has been promised in the last few
versions of the transition plan. Is this happening? (I can tell you for sure
that nobody has asked _me_ to write it :-))

Mike Feldman

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

[Keith Thompson @pulsar]

In article <1993Mar12.160136.6106@evb.com> pole@evb.com (Tom Pole) writes:
> [...]
> If Ada wants to attract/convince/whatever programmers to use Ada, and 
> that it is truly an OOPL, then Ada should use the accepted (de facto standard)
> terminology of OORequirements Analysis, OODesign, OOetc.
> 
> A class is a class. If Ada wants to add the ability to have 
> inheritance/specialization similar to what is available in other
> OOPL's, the OO world calls the common definition
> of a type which supports specialization a class, and instantiations
> of that type objects. Ada can use the same terms if it wishes.
> [...]

Many years ago, when I first read the preliminary Ada reference manual
(the 1979 version), I had a lot of trouble understanding the section
on access types, with its discussion of access values "designating"
objects and so forth.

Not long after that, I realized that access types are (essentially)
what Pascal calls pointer types.  (Pascal was the language I was most
familiar with at the time.)  The current (1983) Ada reference manual
has a note explaining that "Access values are called pointers or
references in other languages" (3.8:10); the 1979 preliminary version
probably had a similar note, but I missed it at first.

Once I had made that connection, I didn't have any problem understanding
what access types are and how they work; most of what I had learned about
Pascal pointer types applied almost directly to Ada access types.

My point is that these minor differences in terminology (pointers vs.
access types, classes vs. tagged types, functions returning void vs.
procedures) really don't matter.  It should take literally no more than
a few seconds to make the connection between similar features in
different languages, once the correlation is pointed out.

Furthermore, as others have mentioned, a C++ class is both a type and a
unit of encapsulation.  The Ada equivalent of a C++ class would be a
package containing declarations for a single type and its operations,
but Ada also allows declarations of any set of logically related
entities to be grouped into a package.  In my opinion, this is a
considerable advantage of Ada over C++.

Ok, so I'm simultaneously arguing that the difference in terminology
doesn't matter because the constructs are the same, and that the
terminology should be different because the constructs are different.
You expect consistency in a Usenet posting?  8-)}

Seriously, I believe that Ada 9X tagged types provide essentially the
same capabilities as C++ classes, in a way that fits well into the
existing Ada 83 framework of packages, derived types, and so on.  I see
little point in making the purely syntactic change from "type Foo is
tagged record ..." to "class type Foo is record ...".  Any more
extensive change, like making classes a unit of encapsulation, would do
too much violence to the overall structure of the language.

The Ada 9X reference manual should probably have a note pointing out
the correlation between tagged types and the various class constructs
of C++ and other object-oriented languages.
-- 
Keith Thompson (The_Other_Keith)  kst@telesoft.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
5959 Cornerstone Court West, San Diego, CA, USA, 92121-9891
"Listen to me, people!  We must stick them with quills -- it's the only way!"

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

[Fergus James HENDERSON]

kst@telesoft.com (Keith Thompson @pulsar) writes:

>I see little point in making the purely syntactic change from "type Foo is
>tagged record ..." to "class type Foo is record ...".

Marketing.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

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

[Harry Koehnemann]

In article <1993Mar13.031104.21673@telesoft.com> kst@telesoft.com (Keith Thompson @pulsar) writes:
>
>Once I had made that connection, I didn't have any problem understanding
>what access types are and how they work; most of what I had learned about
>Pascal pointer types applied almost directly to Ada access types.

And look how the word "access" has completely removed "pointer" or
"reference" from existence in the CS world :).  But really, why take a
very well understood concept and name it something completely off the
wall.  Didn't Ada desire to facilitate understanding, rather than get
in it's way?

>My point is that these minor differences in terminology (pointers vs.
>access types, classes vs. tagged types, functions returning void vs.
>procedures) really don't matter.  It should take literally no more than
>a few seconds to make the connection between similar features in
>different languages, once the correlation is pointed out.

This of course is not true.  The mapping between a Pascal "pointer"
variable and an Ada "access" variable is well understood.  Only minor
semantic differences exist between the two.  However, no such mapping
exists between a Smalltalk/Eiffel/C++ "class" and an Ada "tagged type/
package/generic/task" (objects with separate threads of control).

I'll contend that translating an OO design into the Ada paradigm is not
a straight forward activity for someone raised on these other languages
(if it is a straight forward activity at all).  It is certainly not as
trivial as making the transition from pointers to access types (if you
can call "access" = "pointer" a transition).

>The Ada 9X reference manual should probably have a note pointing out
>the correlation between tagged types and the various class constructs
>of C++ and other object-oriented languages.

This is not as simple as it might seem and if anything would probably
do more harm than good.  If you're going to use a new paradigm, learn
it, understand it, and *then* build smoething in it.  Don't take the
cheesy way out and use some mechanical translation algorithm without
understanding what's being created.  I can already see the subject
line: "Wanted C++ to Ada9X translator".  I'd love to see that Ada code.

>-- 
>Keith Thompson (The_Other_Keith)  kst@telesoft.com
>TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now that's funny.
--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department

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

[Michael Feldman]

In article <1993Mar15.231916.16276@ennews.eas.asu.edu> koehnema@enuxhb.eas.asu.edu (Harry Koehnemann) writes:
>
>I'll contend that translating an OO design into the Ada paradigm is not
>a straight forward activity for someone raised on these other languages
>(if it is a straight forward activity at all).  It is certainly not as
>trivial as making the transition from pointers to access types (if you
>can call "access" = "pointer" a transition).
>
C'mon, guys. Have you ever tried to get a Fortranner to understand
records?  It's not easy but eventually they get it. Have you ever tried
to explain to a Fortranner why Ada does not require that 2-d arrays be
mapped column-by-column? Sure it's a transition, but so what?

If in fact an OO design (in the C++ sense) can't be mapped easily into
Ada9X (and I am still waiting for a real demonstration that this is so),
where is it written that the C++-oriented design was the right one?
Read Rosen's paper on composition vs. class hierarchies (CACM 11/92).

Each new generation of languages brings with it a new set of terms and
a somewhat changed paradigm. Programmers who are raised on Ada have no
trouble with Ada terminology. And the others - IF they are open-minded -
learn it eventually. I've taught Ada to maybe a thousand industry folks
and maybe two thousand university students, and I'm persuaded from that
10 years of experience that an open mind is the most important 
prerequisite. Old Fortran programmers will learn to use Ada well IF
they so desire. Young, geeky C types will not, IF their minds are closed.

So what else is new? Openminded people learn more.

The point of the OO changes to Ada9X was to add new technology to the
language. Technical considerations presumably were more important than
marketing ease. I think Tucker has made the case for tagged types
as a _smooth_ extension from Ada83 and classes as a rather messier one.
Dontcha think it's time to just quit trying to fight a losing battle?
Ada9X-style OOP is in the language. Quit trying to make Ada9X look like
C++, Eiffel, or what have you. Go back to work already.

I am STILL waiting to see a _real_ example of a design of a _real_ system
that is better enough in C++ than it is in Ada to make it worth all this
fuss over terminology. We all know that tagged types vs. classes is NOT
the reason why Ada9X will fail (if indeed it will fail). I'm not going
into all that again.

It's much easier just to trash Ada than to come up with a design that
shows the flaws.

Cheers -

Mike Feldman

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

[Robert Firth]

In article <1993Mar8.153639.3603@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:

>So for some cases, where most operations have only a single
>"interesting" parameter, the class-based approach seems more direct.
>In other cases (like the above), the package-based approach
>seems more direct and supportive of encapsulation.

Thanks, Tucker, and I agree.  Those enamoured of formality might like
to revisit Part I and the first half of Part II of Russell and
Whitehead's 'Principia Mathematica'.  They discuss at great length
the same issue in formal logic: whether relations between two different
classes can be represented adequately in terms of attributes of one
class or the other.  The answer, not surprisingly, is yes, for special
cases, but no, for the general case.  In these terms, the class/attribute
model represents a reversion to the Aristotelian approach, where the
only relations are predication and inclusion.

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

[Robert Firth]

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

>And look how the word "access" has completely removed "pointer" or
>"reference" from existence in the CS world :).  But really, why take a
>very well understood concept and name it something completely off the
>wall.  Didn't Ada desire to facilitate understanding, rather than get
>in it's way?

I'll answer that.  The main reason we used "access" instead of "pointer"
is that "access" is a semantic concept at the level of the language, while
"pointer" is an implementation technique at the level of the underlying
machine.

We had seen the hideous confusion this mistake had caused in other
languages, leading to wrong code, unmaintainable code, and non-portable
code.  Examples of false assumptions caused by the "pointer" terminology
include

	. an access value is a machine (hardware) address
	. an access value and an integer are interconvertible
	. access values with different base types are interconvertible
	. all access values are the same physical size
	. arithmetic on access values can be used in lieu of proper
	  high-level iterators

To anyone familiar with Ada, these propositions are blatantly false.
Replace "access" with "pointer" and they remain false, but almost
invisibly so.

One goal of Ada was reliable programming.  In our opinion, the use of
"pointer" terminology was a major source of almost ineradicable design
and implementation errors in much then current software.  I believe
history has vindicated us.

Robert Firth