billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/09/89)
From article <20600009@inmet>, by stt@inmet: > Here is the wording from the Ada9x project plan: > A revision requirement that does not meet the "upward compatibility" > criteria will only be considered if it affects a very large > portion of the Ada community and its absence in the > revised standard has a serious negative impact on application development. Multiple inheritance, for example, meets both criteria and therefore should be considered regardless of whether or not upward compatibility is affected. Every effort must be made to minimize the difficulty of the transition, but not at the expense of capabilities which are vital to the modernization of our software engineering technology. Saving money on software development is the fundamental motivation behind software engineering, and the fundamental motivation behind Ada itself. If a situation arises in which commercial organizations can use a language which is up-to-date and thereby produce Government software systems at a lower cost than can be achieved by those using a hypothetical 9X which failed to track advancements in software engineering technology, then Ada will have FAILED in its mission. The consequence of this would be that the entire Ada organization would be scrapped. Critics of government would gleefully claim that Ada was yet another example of how anything the government touches becomes inefficient, obsolescent, and doomed to failure. Are they right? Bill Wolfe, wtwolfe@hubcap.clemson.edu
sommar@enea.se (Erland Sommarskog) (10/14/89)
Bill Wolfe writes: >Tucker Taft (stt@inmet) writes: >> Here is the wording from the Ada9x project plan: >> A revision requirement that does not meet the "upward compatibility" >> criteria will only be considered if it affects a very large >> portion of the Ada community and its absence in the >> revised standard has a serious negative impact on application development. > > Multiple inheritance, for example, meets both criteria and therefore > should be considered regardless of whether or not upward compatibility > is affected. Every effort must be made to minimize the difficulty of > the transition, but not at the expense of capabilities which are vital > to the modernization of our software engineering technology. It's not that I have anything against multiple inheritance, rather the opposite, but I'm not 100% sure that it should be included in Ada 9X. It would like throwing the yeast into the oven while the bread is baking. It's easy to say "multiple inheritance" but it should be implemented too. And I'm not talking compiler technology here. My issue is the langauge definition. The inheritance mechanism should integrated with existing constructs in Ada. Say that you add classes a new compilation unit to Ada. Easy? Yes, but why then keep packages? OK, make the classes package types, but somehow I feel that we will ending up having something in the langauge that will be obsolete once we have a inheritance mechanism, multiple or not. And, by the way, isn't there a very simple reason why Ada don't have inhertiance and dynamic binding today? Wasn't that explicitly forbidden in the requirements? Have the requirements changed? (Well, that's not unlikely, because it was not a sound requirement.) Getting inheritance into Ada would give us an Ada++ with the same advantages and disadvantages as C++. Compatible, but at the cost of keeping constructs that shouldn't be there. It is possible that the refusal to accept inheritance in Ada way back in 1980 will mean that Ada never becomes the star as intened. But that might as will be the case if we exclude inheritance from 9X or if we include it. In the latter case because the language gets too large with redundant features. All this said with the following reservation: I haven't seen any concrete proposal on how an inheritance mechanism in Ada should be look like. Therefore is my discussion on the consequences on such a construct somewhat hypothetical, but so is everybody else's too. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se "My baby's a 26. On a scale from one to ten, my baby's a 26." - Chic
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/15/89)
From sommar@enea.se (Erland Sommarskog): > My issue is the langauge definition. The inheritance mechanism > should integrated with existing constructs in Ada. Say that you add > classes a new compilation unit to Ada. Easy? Yes, but why then > keep packages? OK, make the classes package types, but somehow > I feel that we will ending up having something in the langauge > that will be obsolete once we have a inheritance mechanism, multiple > or not. Actually, there are a lot of things which seem "scattered" when one starts thinking about expressing even user-defined types in Ada, regardless of whether inheritance is present or not. For example, currently the language defines attributes for predefined types, and implementations may also define attributes, but a user-defined type can't define its own attributes. The result is that one has to use operations over the type to do "synthetic" attributes. But now we have an inconsistency: for the predefined types we can use the attribute notation (which is actually rather common in object-oriented languages), and all is well. But for the "synthetic" attributes, we must use the subprogram call notation. Why is there this scattering of the attribute concept across the syntax for attributes and the syntax for subprograms? For its time, Ada was an outstanding design, but it seems that the object-oriented concepts were still a little fuzzy and not completely integrated. Properly integrating the various constructs would result in a clean, crisp 9X which will not be subject to the great criticisms of excessive complexity which have plagued Ada 83; if this is done, 9X will be a heck of a lot easier to learn (and adopt) than 83 was. Jean Ichbiah, in "Ada: Past, Present, Future" (CACM, October 1984) commented on the criticism of excessive complexity that regardless of the number of details, complexity depends upon "whether or not it is easy to infer the details from major structural lines"; quite true, but there is some simplification and integration that could be done with these structural lines to make a cleaner product. IMHO, it is probably possible to add multiple inheritance to Ada without cleaning up what in certain areas is a fragmented design, just as it is possible to let that original fragmentation persist. However, the results won't be pretty, and we have an opportunity before us to correct errors of commission as well as of omission. More importantly, though, it will demonstrate Ada's will to survive. COBOL, had it been willing to update itself properly, would over time have turned into what Ada is today (more or less); believe it or not, COBOL started out (Ichbiah, CACM, Oct. 84) with "exactly the same" motives that Ada started with!! Because of COBOL's demonstrated inability to change with the times, the DoD decided to just scrap COBOL completely and start over. I would hope that this fate is not in store for Ada as well. We already are going to have to solve substantial problems with the tasking model, handle the impact of asynchronous exceptions, etc., and there is enough change needed already to ensure that we have every incentive to act now. As long as progress continues to be made in software engineering technology, we cannot stand still. Our inertia must always be a *forward* inertia -- the tendency to keep advancing. Bill Wolfe, wtwolfe@hubcap.clemson.edu
ok@cs.mu.oz.au (Richard O'Keefe) (10/15/89)
In article <6780@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > COBOL started out (Ichbiah, CACM, Oct. 84) with "exactly the same" > motives that Ada started with!! Because of COBOL's demonstrated > inability to change with the times, the DoD decided to just scrap > COBOL completely and start over. COBOL has changed *dramatically* with time. Successive COBOL standards have not merely added new things (like nested programs, terminators on compound statements, new statements) but have also discarded old things (like the ALTER statement). The main complaint that I have heard from COBOL users is that new standards change too much too fast; adapting to a new standard is not just a matter of recompling. In fact there is no shortage of companies that make a living converting other people's old COBOL programs to new standards. COBOL is guilty of a lot of things, but not of standing still.