Vmo: Created page with " From comp.lang.ada Tue Apr 6 11:03:18 1993 Newsgroups: comp.lang.ada Path: utcsri!newsflash.concordia.ca!uunet!world!srctran From: srctran@world.std.com (Gregory Aharonian) Subject: Ichbiah's letter to Anderson: Here it is Message-ID: Sender: srctran@world.std.com (Gregory Aharonian) Organization: The World Distribution: comp.lang.ada Date: Tue, 6 Apr 1993 15:36:39 GMT Lines: 406 By contacting Dr. Ichbiah, I have recei..."

2025-04-29T12:28:06Z

Created page with "<nowiki> From comp.lang.ada Tue Apr 6 11:03:18 1993 Newsgroups: comp.lang.ada Path: utcsri!newsflash.concordia.ca!uunet!world!srctran From: srctran@world.std.com (Gregory Aharonian) Subject: Ichbiah's letter to Anderson: Here it is Message-ID: <SRCTRAN.93Apr6103639@world.std.com> Sender: srctran@world.std.com (Gregory Aharonian) Organization: The World Distribution: comp.lang.ada Date: Tue, 6 Apr 1993 15:36:39 GMT Lines: 406 By contacting Dr. Ichbiah, I have recei..."

New page

<nowiki>

From comp.lang.ada Tue Apr 6 11:03:18 1993
Newsgroups: comp.lang.ada
Path: utcsri!newsflash.concordia.ca!uunet!world!srctran
From: srctran@world.std.com (Gregory Aharonian)
Subject: Ichbiah's letter to Anderson: Here it is
Message-ID: <SRCTRAN.93Apr6103639@world.std.com>
Sender: srctran@world.std.com (Gregory Aharonian)
Organization: The World
Distribution: comp.lang.ada
Date: Tue, 6 Apr 1993 15:36:39 GMT
Lines: 406

By contacting Dr. Ichbiah, I have received permission to post his letter
to Christine Anderson to comp.lang.ada. Here it is. While I can't comment
on the technical aspects of his letter, from a marketing point of view, Ada9X
sounds like a disaster. It may be a great, fantastic language that is under
development, but if Dr. Ichbiah's concerns are even partially valid, than
Ada9X will win even less market share than Ada83. Upward incompatibility,
complexity of features, usurping of roles provided by third party packages,
and stretched out timetables for approval, development and release of new
compilers? This is every marketing manager's nightmare. And given Jean's
involvement with a commercial product oriented company, I would give much
signifigance to his market impact comments. Forget about windows of
opportunity being shut. They will be shut, boarded up, and wired with
explosives.

By the way, does anyone know if the Ada9X effort has a marketing
subcommittee, a group to look into how Ada is going to survive in the
non-Mandated world. I would love to serve on such a committee, but have
not noticed anything.

Greg Aharonian
Source Translation & Optimization
==============================================================================

~Subject: A Farewell to Ada with null
~Date: Fri, 20 Nov 92 00:51:25 EST
~From: Jean D Ichbiah <ichbiah@ajpo.sei.cmu.edu>

~From: Jean D Ichbiah
To: Chris Anderson
cc: DRs, VRs, Iso [other Adaphiles]

~subject: A Farewell to Ada with null

Dear Chris,

For now almost one year, I have tried very hard to work for the
simplification of Ada 9X.

>From the start, I have been very worried by the massive complexity of the
9X proposals. As you certainly remember, this is a concern that I have
expressed to you in earlier correspondance: I was concerned that the
resulting complexity would lose some users as well as some implementers.
I was also seeing a risk that the Ada community would not follow if the
intellectual "distance" and the upward incompatibility were too high.

At the same time I was intrigued by the quality of the individual features
that were proposed - you indeed selected one of the best feature designers
and it is unclear that, on a feature-by-feature basis, better could have
been accomplished. And I was hoping that the DRs and Iso processes would
bring a reduction to an acceptable size, to something that is intellectually
manageable. I was also hoping that it would be ultimately possible to dress
the new concepts in a simpler, more regular, more attractive, more beautiful
syntax, which could redeem some of the complexity. And it is fair to say
that I was encouraged in that hope by a very favorable mail response on the
network.

It is now time for me to acknowledge that my efforts have failed.

Unfortunately, I have encountered an unusual degree of intolerance to
outside contributions which meant that more time was spent fighting my
attempts to improve than analyzing their merits. This was clearly becoming
counterproductive and at the Iso meeting in Salem, my attempts to simplify,
supported by 2 and opposed by 2, ultimately lost to 6 courageous abstentions.
This happened according to the rules and the outcome is not one that can be
disputed.

Nevertheless, I do not like the current proposal. (Of course, in all
fairness, I will withhold final judgment until the proposal is final - my
inveterate, irrational optimism again.) More than most people, I am driven
by aesthetic considerations and the strong belief that only beautiful shape
can be correct shape. And for me, a striking symbol of the lack of
aesthetic considerations in the new proposals are contained in the construct

with null

coldly logic, ultimately ugly - the engineers had it their way and had Ada
9X become Ada with null.

Alltogether, my impression of the present proposal reminds me of my awe when
first crossing this bridge in Boston: the Mystic River Bridge. It certainly
met the requirements but the accumulation and clutter of metal was
oppressive and threatening and ... my preference will always go to the
Golden Gate Bridge. The first had engineered features, the second had an
Architect and a prodigious Architecture with charm.

But my discomfort with the course in which 9X appears to be irreparably
engaged goes well beyond the aesthetics. I will review the main ones in what
follows.

THE EXPLOSION OF COMPLEXITY

A massive increase in complexity, will result from 9X adding one or more
additional possibilities where Ada now offers two. For example, 9X adds:

* root types, to types and universal types

* aliased, to constant and variable

* inherently limited, to limited and not limited

* protected types, to subprograms, packages, and tasks

* decimal and unsigned types, to integer and real types

* access parameters, to in, out, and in out

* accessibility and dynamic accessibility, to scope and visibility

* accessibility checks, to constraint checks

* tagged types, to normal types

* dispatched subprogram calls, to normal subprogram calls

* use type clause, to use package clauses

* barriers, to conditions ...

Now, if 10 of these interact and with an average 2 possibilities in each
case, we roughly have 1000 possible interactions in current Ada (that is,
2**10). But 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).
As you see, it is very legitimate to talk of an EXPLOSION in complexity if
it has been multiplied by 60! Some will argue that an interaction on 10
planes is unusual. But even with 5 planes, we get a very significant
increase by a factor of 8 (since 2**5 is 32, and 3**5 is 243).

Clearly, some of the above extensions are desirable. But taken altogether
they result in an undesirable complexity.

EXTRA COMPLEXITY IS OBJECTIONABLE

Extra complexity, to this degree, is very objectionable for implementers and
the Ada industry.

On one hand, it will delay and significantly increase the effort of building
compilers, with the risk that some vendors will drop out of the market.
(I understand that you intend to relax the validation requirements in the
short term. But this abandon of the no-subset rule will have Ada lose one
of its major advantages over competing languages: the high degree of
compatibility between implementations.) For the surviving vendors, the
scale of changes is likely to set them back by several years in terms of
reliability and performance of implementations. (Whatever comfort would
come from the prototype implementations is illusory. They are test-tube
experiments that have concentrated on certain facets; they have not been
able to test the interactions of features.)

Moreover, the additional effort required by this complexity will compete for
resources and thereby prevent the Ada Industry from investing sufficiently
in interfaces. I have said it several times before, but it is worth
repeating: I consider the lack of interfaces to be the most severe
impediment to increasing usage of Ada - witness the absence of a credible
Ada solution for Windows development - and this diversion of resources from
interfaces severely diminishes the chances for Ada's long term success.

The extra complexity is equally objectionable from a user's point of view.

Ada has provided so far an attractive base for software engineering and for
the development of large reliable programs. Ada struck at the right level:
more complex than Pascal - since it offered facilities that the users needed
- - but not as complex as C++. So it meant that average programmers could
develop a level of command of its concepts with which they could develop
programs whose structure, actions, and consequences they understood and
mastered - an absolute requirement for reliability.

But this simplicity does not appear to be preserved with the 9X current
proposals, whose complexity are likely to be beyond that of C++. And if we
were to lose the simplicity advantage over C++, what would remain of the
advantages of Ada?

Finally, the extra complexity is very objectionable because the resulting
delays severely endanger the chances of positioning Ada in the main stream
of object-oriented programming. We run the risk of missing the window of
opportunity.

THE ILS APPROACH AND MORE DELAYS

The current approach taken for specifying the language is based on the
so-called ILS (the Integrated Language Specification). The sheer size of the
document should be a severe warning about the complexity of the current
proposals: It is larger than the Ada Reference Manual although it purports
to describe the changes with respect to this former manual.

But the most striking aspect of the ILS (beyond the size) is the
uncontrolled proliferation of new jargon, replacing or adding a large number
of new technical terms. The developers of the ILS have argued that this is
a temporary document whose purpose is to specify the changes and that their
intent is to develop a Revised Reference Manual in the style that has been
so successful for Ada (83).

On one hand, the level of details covered in the ILS have certainly helped
in revealing the interactions of the new features and, thereby, their
complexity.

However, the approach is unlikely to work: In refining the language
proposals, the small local decisions are going to be very influenced by the
terms that are used. The words we use influence the concepts: they often
dictate technical choices that keep the description simple and
understandable. This has been my experience with the formulation of the
Green manual, and that of the Ada 80, and Ada 83 reference manuals. The ILS
approach tries to postpone the difficulty but it will mean that these local
trade-offs will be done in terms of the ILS jargon and will have to be
redone when you scale down the terminology to the style of the final
reference manual.

As this will take a lot of time, the temptation will be to have the
standard be an ILS-style document. If this were to happen, Ada would lose
another of its key advantages - that of having a standard that is readable
by most programmers, to the degree that compilers formulate error messages
in terms of sections of the reference manual. This approach would also lose
the "intellectual capital" invested by the Ada community in the
understanding of the Ada definition.

>From where we are now, I regard the current goal of having a draft reference
manual in June 1993 as unrealistic by at least six to nine months. (Unlike
Cassandra, I speak here with experience. Like Cassandra, however, I may
share the dual attributes of being right and not believed.) The ILS
approach is actually postponing the moment where the team will be in a
position to understand the complexity of what they are trying to do, as well
as the complexity of describing their proposals. So it is postponing the
time when they will be able to give a reasonable estimate of completion
time.

UPWARD INCOMPATIBILITY

I am also worried at the growing level of upward incompatibility of 9X with
Ada. As a measure of this growing divergence, the list published in the
November 92 issue of Ada letters contained 12 categories of upward
incompatibilities. A more recent list, compiled from the ILS now counts
some 30 different categories (and this is not just a different
categorization). While a small number of them are language improvements
(for example, the better enforcement of a contract model for generic units)
many of them reflect an attitude that is too tolerant of upward
incompatibility (for example, the elimination of accuracy constraints in
subtypes and that of named notation for operators).

Upward compatibility shoud be addressed much more strictly. Success of 9X
will not happen unless it is a superset of current Ada: Existing compilers
will have to be maintained for their current applications and the resources
do not exist to maintain two separate families of compilers. Moreover, very
strict upward compatibility is a prerequisite for the strategy of gradual
introduction of 9X features in existing Ada compilers.

WHAT WAS AND IS NEEDED

What we have seen is a reflection of the inherent inability of committees to
make choices. In this respect, it should be no surprise that the decision
process has led to this overweight since historical precedent of efforts to
achieve similar consensus have had similar results for other languages
(PL/I ...). Moreover, we have had to face the unusual situation of a team
who has been pushing for always more features. The combination has produced
the current inflation.

With the 9X revision process, we were considering a language revision, as
opposed to the design of an entirely new language. It seemed therefore, that
the rules implied that improvements had to be sought within the frame of the
existing language and with a certain modesty that did not exclude an
occasional "cadenza" for the revision team.

In this spirit, the key decision was the choice of ONE major area where the
revision would decide to concentrate efforts to extend current Ada. The rest
being a collection of smaller scale - and nevertheless important - decisions
such as the international character set and various local improvements
(aggregates, preferences, ...).

Along with many others, I have argued that this area of focus should be the
Object-Oriented Programming features (including the ability to pass
subprograms as parameters). The semantics developed for these features is
indeed quite attractive (even if the syntax badly needs improvement).
The priority for OOP comes from a real market requirement - these features
will attract new users to Ada - and also from the ability to reuse the
significant work that was done in libraries of classes for C++ and Turbo
Pascal. So it is part of the effort to interface Ada with the outside world
and to reuse software and methods that are developed outside Ada.

If we limited the revision to this level, we could certainly have something
rather elegant, well in the spirit of Ada, which could be ready within the
original schedule, and for which implementations could be achieved rapidly
and in an upward compatible manner.

The current trouble comes from having tried to achieve consensus by
satisfying all user communities and - in part - this is what has led to the
proposed plethora of new features and the ensuing complexity. I have argued
in other places that, since we had to choose, we had to be more modest in
the area of real-time, perhaps addressing only improvements in the area of
priority handling.

The logic behind this choice is that we are dealing with a community that is
already using Ada for moderately time-critical applications. When they are
not using Ada tasking, they are working with some set of packaged real-time
primitives: Cifo, Extra, Posix, or some other proprietary kernel. At the
other end of the spectrum, for extremely time-critical applications, they
are working with packages of even lower-level primitives.

In most cases, these packaged solutions were adopted because it was
considered that they offered the best combination of advantages: the Ada
modularity and reliability, and the real-time primitives offered by the
package. Moreover, when outside interfacing reasons dictate the choice of
primitives, such as Posix, nothing that we do in Ada is likely to change the
approach. Given the level of consensus achieved for these packaged
approaches in their respective areas, and given the need fore interfacing
with other languages, it is very unlikely that the corresponding user
communities would switch to a different approach - even if they found new
Ada features to meet their requirements. Consequently, the Ada industry
will have to provide support for these packaged approaches regardless of
what is done by the language revision.

Moreover, the choice of Ada over some competing language such as C or C++
is not going to depend on the presence of tasking features since these
competing alternatives do not have any. On the contrary, the presence in
9X of features that they do not use could be an argument for not using the
language as people fear the distributed inefficiencies that are commonplace
for implementation of new languages (and with the level of change presently
contemplated, 9X would be a new language to which the fine-tuning that took
place for Ada in the past ten years would not apply).

So the above considerations show that any effort that we expend on real-time
features has a low return on investment as far as attracting users to Ada.
Hence this is an obvious area for substantial reduction.

Others depend more on containing the team's natural inclination to add more
features. I will limit myself to two significant examples.

The first feature is the introduction of discriminant for classes. This is
something that exists in no other language that has OOP features, and
apparently for good reasons when we see the complexity that the interaction
of classes and discriminants has induced in 9X. Besides complexity, the
other reason why other languages have avoided discriminants for classes is
that they are not that useful for the dynamic style of programming that is
customary for the applications contemplated. Discriminants serve for static
parameterization, but the style of programming used for, say windows
applications, liberally uses dynamic creation and quite justifyably so when
you consider the decreasing costs of processors. So this is the domain of
late binding, of dynamic dispatching, and if you need to have a string, you
naturally allocate it dynamically (where a static view would have used
discriminants). So the inability to sort out objectives, and to choose,
results in significant complexity without real gain.

The second example is in the area of separate compilation. Early Ada
compilers were slow and the need to optimize compilations was very acute.
Fortunately, you can now compile well over 100,000 lines in an hour on a
very low cost machine (a 486) so that this is now a problem of the past.
But this problem of the past has resulted in the 9X feature of hierarchical
libraries.

I will argue that this is again unneeded complexity. First, we have to
recognize that current Ada already goes much beyond other languages for
separate compilation of interfaces. Other languages such as Turbo Pascal
for Windows do allow a form of package - the Pascal units - but the
interface and the body are one single text. So you would expect Turbo
Pascal compilation to be slow ... except that the compiler is smart enough
to distinguish changes to the interface from changes to the implementation.
This shows the path: if you still think that the kind of compilation
optimization that motivates hierarchical libraries is relevant, you can
achieve it by a more sophisticated compiler without need to increase the
size of the language. The feature may be well-designed, but it is
nevertheless dead weight. In addition, it has been shown to undermine one
of the most valuable conceptual assets of Ada: the safety of packages (with
unwanted self-proclaimed children getting access to the private part).

The fact that a feature is well designed does not mean that it has to be
part of the language: designing the architecture of a programming language
is about choice and responsible choice is always "either/or", rarely "all
of". Failing to choose will mean more to learn, more to implement, less
efficiency, and less chances for Ada to succeed.

CONCLUSION

I have certainly hesitated before sending this open letter. Some very good
friends have expressed concerns about possible negative impact on Ada.
Clearly, my present assessment of the situation is quite different and
I think that the 9X program requires a very substantial reorientation to
succeed: I see more risk in continuing in the present course than in
attempting a courageous reorientation.

Others who share my concerns have reacted on the assumption that, anyway,
it is too late. My hope is that this is not the case, and my belief is that
the current plans and schedules are unrealistic to the degree that a
reorientation is the only way to achieve something in a reasonable time.
In 1981, Larry Druffel sponsored a parallel group - Emilion - to study an
alternative. This could be an example to follow.

In acknowledgment of the fact that it has not been possible for me to make
an effective contribution, and also in view of my reluctance to be
associated with something whose complexity I disapprove and whose aesthetics
I can neither see nor share, I will no longer participate to Distinguished
Reviewers meetings and would like my name to be removed from the list.
I will see if I can be more effective from outside the group (for that matter,
I would like to be on the list of Volunteer Reviewers).

I was looking forward to be one of those promoting 9X but this does not
appear to be possible at the present time.

Sincerely,

Jean D. Ichbiah
Architect of the Ada Language

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

</nowiki>

← Older revision		Revision as of 14:28, 29 April 2025
Line 1:		Line 1:
	<~~nowiki~~>		<pre>

	From comp.lang.ada Tue Apr 6 11:03:18 1993		From comp.lang.ada Tue Apr 6 11:03:18 1993
Line 423:		Line 423:
	P.O. Box 404, Belmont, MA 02178		P.O. Box 404, Belmont, MA 02178

	</~~nowiki~~>		</pre>

J Ichbiah mail 20 nov 1992 - Revision history

Vmo at 12:28, 29 April 2025