The A-Z of Programming Languages: Ada, interview with S. Tucker Taft

http://www.techworld.com.au/article/...uages_ada?pp=1

--
Ludovic Brenta.

Ludovic Brenta schrieb:
> http://www.techworld.com.au/article/...uages_ada?pp=1
>

Has Ichbiah been right to be skeptical of Ada 95's OO?
It does seem to have, uhm, rich structure, seen from a
learners point of view.

-- Georg

Georg Bauhaus wrote:
> Ludovic Brenta schrieb:
> > http://www.techworld.com.au/article/...uages_ada?pp=1
> >
>
> Has Ichbiah been right to be skeptical of Ada 95's OO?
> It does seem to have, uhm, rich structure, seen from a
> learners point of view.

This prompts the question: how would Ichbiah have implemented OOP in
Ada?

--
Ludovic Brenta.

Ludovic Brenta wrote:
> Georg Bauhaus wrote:
>> Ludovic Brenta schrieb:
>>> http://www.techworld.com.au/article/...uages_ada?pp=1
>>>
>> Has Ichbiah been right to be skeptical of Ada 95's OO?
>> It does seem to have, uhm, rich structure, seen from a
>> learners point of view.
>
> This prompts the question: how would Ichbiah have implemented OOP in
> Ada?

Perhaps barely, if at all.

I was at an Ada conference in the early 90s where Ichbiah was a keynote
speaker, and talking about the Ada 9X revision process that was just
then getting underway.

The only thing I clearly remember him stating in his presentation was
that Ada 9X was not going to allow "any elephants in the tent".

And I think OOP, in the context of Ada 83, would certainly qualify as an
elephant. No matter how elegantly one might have conceived it.

Subsequent to that presentation, as Tucker mentioned in the interview,
Ichbian left the revision effort.

Marc A. Criley
McKae Technologies

Marc A. Criley schrieb:
> Ludovic Brenta wrote:
>> Georg Bauhaus wrote:
>>> Ludovic Brenta schrieb:
>>>> http://www.techworld.com.au/article/...uages_ada?pp=1
>>>>
>>>>
>>> Has Ichbiah been right to be skeptical of Ada 95's OO?
>>> It does seem to have, uhm, rich structure, seen from a
>>> learners point of view.
>>
>> This prompts the question: how would Ichbiah have implemented OOP in
>> Ada?
>
> Perhaps barely, if at all.

This seems surprising because classwide programming and
dynamic dispatch seem to have been among the requirements of Ada 9X.
(I got this idea from browsing the archives.)

In an excerpt from a letter sent by Ichbiah to the Ada 9X group,
a part of which is quoted in Meyer's OOSC2, Ichbiah appears to
be addressing the increased complexity of the language,
which is caused by the then new features and their combinations.
He computes it to be approaching ~60_000 combinations.
(I'll look up the details.) Might Ichbiah have thought that
by some 80/20 rule, you can overdo things if you create Ada 9X
the way it was around 1992?

IIUC what Taft says in the interview, Ichbiah didn't like the
_way_ OOP was to be implemented. OTOH he had been working on a
Simula compiler at INRIA. So maybe OOP alone was not the elephant.

Georg Bauhaus a écrit :
> IIUC what Taft says in the interview, Ichbiah didn't like the
> _way_ OOP was to be implemented. OTOH he had been working on a
> Simula compiler at INRIA. So maybe OOP alone was not the elephant.
>
Certainly. Actually, Ichbiah was well aware of the benefits of OOP, and
actually that's why he insisted for having derived types in Ada83,
against the opinion of the rest of his team.

--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

On Thu, 05 Jun 2008 09:58:36 -0400, Georg Bauhaus
<rm.dash-bauhaus@futureapps.de> wrote:

> IIUC what Taft says in the interview, Ichbiah didn't like the
> _way_ OOP was to be implemented. OTOH he had been working on a
> Simula compiler at INRIA. So maybe OOP alone was not the elephant.
>

I wasn't there, but rumor had it that JDI wanted to use the term "class"
(rather than "tagged type") for consistency with other OO languages. I
don't know what his other disagreements were.

Jean-Pierre Rosen wrote:
> Georg Bauhaus a écrit :
>> IIUC what Taft says in the interview, Ichbiah didn't like the
>> _way_ OOP was to be implemented. OTOH he had been working on a
>> Simula compiler at INRIA. So maybe OOP alone was not the elephant.
>>
> Certainly. Actually, Ichbiah was well aware of the benefits of OOP, and
> actually that's why he insisted for having derived types in Ada83,
> against the opinion of the rest of his team.

Thanks.
As promised, here is what Meyer quotes from Ichbiah's resignation
letter:

"A massive increase in complexity will result from 9X adding one or more
additional possibilities where Ada now offers two. For example, 9X adds:
[...] access parameters, to IN, OUT, and IN OUT; tagged types, to normal
types; dispatched subprogram calls, to normal subprogram calls; use type
clause, to use package clauses; ... With 9X, the number of interactions
to consider is close to 60,000 since we have 3 or more possibilities in
each case (that is, 3^10)." (OOSC2, §33.7, p.1095)

The comment "adds: tagged types, to normal types" is particularly
interesting, I think, because it touches on a consequence of
this distinction: sloppy versus exact base type systems:

Eiffel tries to have basically one kind of type definition,
namely the class---even though "expanded class" "adds one or more
additional possibilities", if I may aim Ichbiah's comment at
Eiffel. Compiler magic is/was used for types such as INTEGER or REAL.
Some operations of INTEGER are "require"-predicates used for testing
whether or not an integer value fits a subsets of INTEGER,
e.g. 8-bit integers.

Ada, as mentioned by Ichbiah, has "normal" types for defining
integers, reals, etc., and tagged types for defining polymorphic types.
You want integers between 0 and 10_000 only? Define a corresponding
normal type, or do "normal" derivation from another integer type
adding the needed constraint.
(Part of the language since Ada 83 as pointed out by J.-P. Rosen above.)

What I find so interesting is that these ways to define basic types
might show that there are undeniable reasons to require two type
definition mechanisms. (I guess this is not news to people who worked
on either Ada 9X or Eiffel, but it appears to be news to a new audience
tackling the base type system. And the presence of one or the other
always affects programs.)

Do the Eiffel base types work well? Do they match the "normal"
integer types of Ada in practice? Using cut&paste polymorphism
and renaming one can change INTEGER to a different INTEGER with more
specific require predicates, predicates even more powerful than Ada's
range constraints(*). Still, people coming to Eiffel have more than
once asked for more programmer control of basic Eiffel types such as
INTEGER and FLOAT. Messing with base types, renaming and cluster
management do not look like the best solution.

So maybe there is good reason to have both normal types, and tagged
types, even if this complicates the language?

_____
(*) Some hard work has been done with the goal of enhancing
Ada's type constraints in the sense of DbC. It has been published
as AIs and elsewhere.

X'Post
-- Georg Bauhaus

On Thu, 05 Jun 2008 21:40:55 +0200, Georg Bauhaus wrote:

> "A massive increase in complexity will result from 9X adding one or more
> additional possibilities where Ada now offers two. For example, 9X adds:
> [...] access parameters, to IN, OUT, and IN OUT; tagged types, to normal
> types; dispatched subprogram calls, to normal subprogram calls; use type
> clause, to use package clauses; ... With 9X, the number of interactions
> to consider is close to 60,000 since we have 3 or more possibilities in
> each case (that is, 3^10)." (OOSC2, §33.7, p.1095)

I cannot decode this, so let it be...

> The comment "adds: tagged types, to normal types" is particularly
> interesting, I think, because it touches on a consequence of
> this distinction: sloppy versus exact base type systems:

In which sense "sloppy/exact"?

> Ada, as mentioned by Ichbiah, has "normal" types for defining
> integers, reals, etc., and tagged types for defining polymorphic types.

Tagged types aren't polymorphic. Only their classes (closures of) are.

> You want integers between 0 and 10_000 only? Define a corresponding
> normal type, or do "normal" derivation from another integer type
> adding the needed constraint.
> (Part of the language since Ada 83 as pointed out by J.-P. Rosen above.)

Well, I understand this complain. Actually, there is no semantic difference
between:

subtype S is T ...; -- "Normal" derivation

and

type S is new T with ...; -- "Abnormal" derivation

and with Ada 2005

type S is interface and T; -- "Horrific" derivation

Clearly, all of them should have same syntax. Clearly interfaces are
superfluous when abstract types could do anything they do and more.
Further, interfaces are damaging to software design. One is forced
permanently factor out interfaces out of types instead of trivial interface
inheritance from concrete types.

> What I find so interesting is that these ways to define basic types
> might show that there are undeniable reasons to require two type
> definition mechanisms.

Really? I'd like to deny some of them. (:-))

> So maybe there is good reason to have both normal types, and tagged
> types, even if this complicates the language?

No, there is no substantial difference between two mechanisms, once one has
separated polymorphic (class) and specific (type) as Ada 95 did, all types
become "normal." Abnormal are classes, which you aren't forced to use as
they are completely orthogonal to "normal" types.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Ludovic Brenta wrote:
> http://www.techworld.com.au/article/...uages_ada?pp=1

Not yet slashdotted (I'm a bit surprised) but there are some nice
comments on OSNews:

http://www.osnews.com/comments/19824

--
Ludovic Brenta.