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