wtwolfe@hubcap.clemson.edu (Bill Wolfe) (09/29/89)
Ada is now entering the revision process, and much has transpired
over the last ten years. Many ideas have emerged, both from inside
the Ada community (e.g., Hilfinger's ideas to the effect that literal
recognition should not be limited to the predefined types, but should
in fact be definable for user-defined abstract data types as well),
and from outside the Ada community (notably multiple inheritance).
When Ada was first designed, the objective was to provide the maximum
possible support for good software engineering practices, given what
was then known about programming language technology. Unfortunately,
compiler maturity is just now reaching levels which make the language
attractive as a production tool, and in the meantime the continuing
advancement in the theory and practice of programming language design
have made the delay very costly to Ada's prospects for widespread
acceptance.
Moreover, some persons who have been in a position to observe the
Ada community seem to be of the opinion that for a significant
number of members of the Ada community, Ada 83 has become an end
rather than a means; in their estimation, Ada will fall victim to
the resistance to change which seems to plague virtually all human
endeavors. They cite the recently expressed view that inheritance
would result in too great a setback for Ada compiler maturity as
an example, saying that inheritance has already been proven to be
efficiently implementable and that this is merely a smoke screen
for resistance to new concepts.
Therefore, I would like to pose this question to the Ada community:
what are the basic objectives of Ada 9X? Specifically, is Ada going
to be something that is tied to the idea of maximum support for the
practice of software engineering? Is the DoD *really* committed to
making Ada the primary vehicle of software engineering technology?
If so, what is being done to close the gap between the dream of
widespread Ada use and the reality of the widespread use of COBOL,
C, C++, and Eiffel instead?
I do not mean to imply that tremendous progress has not been made;
as John Foreman (I believe) recently noted, Ada is much farther along
than COBOL was at a similar point in its existence. However, it is
extremely frustrating to see people choosing C++ and Eiffel instead
of Ada because of this ten-year revision cycle (and perhaps a bad bet
that inheritance would not turn out to have a bright future). It is
extremely frustrating to see employment advertisements calling for
knowledge of the likes of C or COBOL, with nary an Ada advertisement
in sight. But the worst of all is listening to people assert that
Ada is obsolescent and will never be able to catch up.
As a software engineer, I strongly believe in the Ada dream. But
there have been big problems associated with realizing that dream.
An explicit linkage of Ada 9X to maximum support for the software
engineering process, combined with a shortened five-year revision
cycle, would go a VERY long way toward making that dream a reality.
Bill Wolfe, wtwolfe@hubcap.clemson.eduryer@inmet.inmet.com (09/30/89)
RE: /* Written 9:59 pm Sep 28, 1989 by wtwolfe@hubcap.UUCP in inmet:comp.lang.ada */ /* ---------- "Ada 9X objectives" ---------- */ > ... (notably multiple inheritance). > ... Unfortunately, > compiler maturity is just now reaching levels which make the language > attractive as a production tool, and in the meantime the continuing > advancement in the theory and practice of programming language design > have made the delay very costly to Ada's prospects for widespread > acceptance. > ... They cite the recently expressed view that inheritance > would result in too great a setback for Ada compiler maturity as > an example, saying that inheritance has already been proven to be > efficiently implementable and that this is merely a smoke screen > for resistance to new concepts. > Bill Wolfe, wtwolfe@hubcap.clemson.edu /* End of text from inmet:comp.lang.ada */ If it costs $500k each to add a high quality multiple-inheritance type system to Ada compilers, and there are 15 separate baselines (FE's), then the cost of the feature (at high quality) is $7.5M. Will enough C++ and Eiffel users go out and buy one to cover the investment? Should the DOD: A. Require a full class/inheritance/etc system in Ada 9X AND prohibit the use of Eiffel, C++, Simula, etc. in RESEARCH as well as in major production programs in order to force an adequate market to be created? or B. Put in Ada 9X only what the current market is large enough to pay for? or C. Put in multiple inheritance and let the quality and availability of compilers settle wherever it may? or D. <fill in the blank> Please don't take this note as a flame: I see the Ada 9X contents issue as being primarily one of economics, not cultural inertia. I would be quite interested in comments about how the "won't-use-it-unless-its- good-and-it-won't-get-good-unless-you-use-it" stalemate can be broken. I'm hoping the 9X Requirements Team will ask for "enough building blocks so you can do object oriented programming reasonably well without revising the entire type system". Mike Ryer (working, but not speaking, for Intermetrics (an Ada, C, and other language compiler vendor, applications developer, and contract research company, which believes in using the best available software engineering technology as much as anyone, but is also a for-profit business.))
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/03/89)
From ryer@inmet.inmet.com: > [Cost of an Ada class/inheritance system: $500K/compiler] > [...] I see the Ada 9X contents issue > as being primarily one of economics, not cultural inertia. I would be > quite interested in comments about how the "won't-use-it-unless-its- > good-and-it-won't-get-good-unless-you-use-it" stalemate can be broken. My article was not necessarily about inheritance in particular, but rather about the need to make Ada a function of software engineering technology as of each revision point. Beyond that, I'd just like to note that in general, the longer a necessary change is delayed, the more painful it becomes. Furthermore, if Ada ever becomes decoupled from major advances in software engineering technology, then Ada will have no future. IMHO, Ada must either grow now or die in the nursery. To further stimulate this discussion, I'm reposting below a recent article from comp.sw.components, where a similar discussion has been recently taking place. I believe Mr. Crawley's views are shared by a large number of people outside of the Ada community. Bill Wolfe, wtwolfe@hubcap.clemson.edu ------------------------------------------------------------------------- From scc@cl.cam.ac.uk (Stephen Crawley) Newsgroups: comp.sw.components Subject: Are "production" programming languages dinosaurs? Bill Wolfe writes: > Ada is the result of a language ENGINEERING process. There was > a deliberate decision that the definition of the language would > be held stable for ten years at a time. This permits certain > economic assumptions to be made, which was judged to be more > important than satisfying those who think that new versions of > a language should be generated every six months. This is a > PRODUCTION language, not a RESEARCH language. It offers a lot > of advantages (portability, compiler validation, infrastructure) > not present with other languages, in addition to a very high level > of support for good software engineering practices. Well how come ADA seems to be largely irrelevant outside of the defense sector? ADA 83 was 5 - 10 years out of date even before it was finalised. Unless it gets a RADICAL overhaul, ADA 9x will be 10 - 15 years out of date. Doubtless, the reasctionaries and religious zealots from the software engineering industry will make sure that much of the important work done by researchers over the last 15 years (like GC technology, functional programming, designing languages to make formal verification possible) will be ignored ... just like they did for ADA 83. > We are nearing the end of the ten-year period of definitional > stability, and obviously this is when the number of new ideas > which have not yet been incorporated is at its largest. Sadly ADA 83 isn't anywhere nearing the end of its life ... even for writing new software. It would be very optimistic to expect ADA 9x software development environments to be available before 1995, which puts ADA 83 only 1/2 way through its life. And even that is ignoring the inertia inherent in the software development process. I can't see many project managers leaping to ADA 9x half way through a large project. -- Production language design should be an on-going evolutionary process. The language design should reviewed regularly to incorporate new proven ideas from research languages and the results of experience from the production language itself. A new language version every 2 years sounds about right to me. Production language designers should also avoid the pitfall of excessively compromising the language design for backwards compatibility. Outdated ideas and language constructs should be phased out as quickly as possible. What about all the software in old versions of the language? Who does the job of converting it I hear you ask? It should be the task of the people who build programming support environments to write conversion tools to largely automate the task of converting code from one version of the PL to the next one. Maybe these ideas are not workable right now ... production programming support environments aren't really up to the task yet. But this is the direction the Software Engineering industry should be aiming. The process of change in computing is inevitable; we should be going with the flow not trying to hold back the tide. -- Steve
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/03/89)
In an earlier comp.lang.ada article I included a copy of a recent article from Stephen Crawley in comp.sw.components. I'd like to comment here on some of the points raised. > Well how come ADA seems to be largely irrelevant outside of > the defense sector? That depends strongly on your definition of "largely irrelevant"; there is a large and growing number of non-defense projects and companies using Ada. The new generation of highly optimizing Ada compilers deserves at least some of the credit for this substantial and accelerating growth. > ADA 83 was 5 - 10 years out of date even before it was finalised. Unless > it gets a RADICAL overhaul, ADA 9x will be 10 - 15 years out of date. > Doubtless, the reasctionaries and religious zealots from the software > engineering industry will make sure that much of the important work done > by researchers over the last 15 years (like GC technology, functional > programming, designing languages to make formal verification possible) > will be ignored ... just like they did for ADA 83. In fact, this is not correct. Ada 83 explicitly provides for garbage collection as an optional compiler service. The rule that functions must not modify their parameters was probably a direct result of functional programming ideas. Finally, formal verification is a major goal of the software engineering community, and Ada was designed to support it to as great an extent as possible. For example, the use of the termination model of exception handling was (at least in part) motivated by formal verification considerations. > Production language design should be an on-going evolutionary process. > The language design should reviewed regularly to incorporate new proven > ideas from research languages and the results of experience from the > production language itself. A new language version every 2 years sounds > about right to me. This is too frequent; five years might be reasonable, but not two. I don't think the compiler validation suites, etc., would be able to respond meaningfully to a revision cycle which was THAT frequent. > What about all the software in old versions of the language? Who does > the job of converting it I hear you ask? It should be the task of the > people who build programming support environments to write conversion > tools to largely automate the task of converting code from one version > of the PL to the next one. The US Government is actively planning to maximize the use of automatic translation technology during the transition from Ada 83 to Ada 9X. > Maybe these ideas are not workable right now ... production programming > support environments aren't really up to the task yet. But this is the > direction the Software Engineering industry should be aiming. The process > of change in computing is inevitable; we should be going with the flow > not trying to hold back the tide. On this I agree. But another good reason to only revise no more quickly than five years at a time is to give new ideas a chance to mature. Once a new idea has proven itself, and has become reasonably agreed upon to be a good thing that production languages should have, there should be a process by which production languages incorporate new developments in software engineering technology, and this is what should be accomplished by the Ada 9X scheduled revision process. Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/03/89)
From ryer@inmet.inmet.com: > If it costs $500k each to add a high quality multiple-inheritance type > system to Ada compilers, and there are 15 separate baselines (FE's), > then the cost of the feature (at high quality) is $7.5M. Will enough > C++ and Eiffel users go out and buy one to cover the investment? Look at it this way: if Ada 83 is not upgraded to reflect recent advances in software engineering technology, then your investment in Ada in general will go down the tubes along with the language. We already know from a number of articles (e.g., "Comprehensive Scheduling Controls for Ada Tasking", Tzilla Elrad, Ada Letters, Fall 1988, and "Programming Atomic Actions in Ada", A. Burns and A. J. Wellings, Ada Letters, September/October 1989) that the entire Ada tasking system is going to have to be overhauled. A good inheritance/class system in Ada 9X should be introduced now along with this overhaul of the tasking system; I personally think that if this is done, the resulting growth of Ada will provide rich rewards to the compiler vendors who followed. Comments were made at Tri-Ada '88 to the effect that while there are real risks associated with changing (to Ada), there are even larger risks (competitive risks) associated with NOT changing, and this is what must be brought home to those organizations which are still using the older languages. Perhaps we would do well to heed our own advice. Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/06/89)
From jbg@sei.cmu.edu (John Goodenough): > no one yet knows what the likely changes might be, because the change > requests have not yet been analyzed against the stated goals of the > 9X process... I would tend to rather strongly doubt that any significant number of the change requests appearing in the places I described will be in conflict with the stated goals of 9X. > "to revise ANSI/MIL-STD-1815A to reflect current essential requirements > with minimum negative impact and maximum positive impact to the Ada > community. The Ada 9X process is a revision and not a redesign of the > language and should be viewed as a natural part of the language maturation > process." [From the Ada 9X Project Plan, January 1989] > > In my opinion, this means the goal is to improve the usability of Ada, and > this means fixing problems while not destabilizing the adoption process or the > quality of Ada implementations. How this can be done will be the subject of > much discussion in the next few years, but major and widespread > incompatibilities certainly are not consistent with the stated goals. Major and widespread incompatibilities which do not offer strong advantages would not be consistent, but where a strong advantage is to be gained (e.g., the ability to apply a high-powered multiple inheritance system), the magnitude of the positive impact would certainly overcome the possibility that an automatic translator might be required. This is completely consistent with the language maturation process, and corresponds directly to the continuing maturation of the software engineering process. My contention is that if 9X does not track the state of the art with respect to the software engineering process, then the adoption process will be "destabilized" completely, since more modern languages which provide better support for the software engineering process will be used instead. THAT is inconsistent with Ada 9X objectives. > It is certainly premature to suggest that some kind of automatic > translator will be required. In fact, I think most people involved > with the effort would be appalled if something called an "automatic > translator" from Ada 83 to Ada 9X was required. What I am suggesting is that it would be an extremely good idea to assume that this will be the case. If not, fine; but given the amount of evolution which has occurred with respect to the language capabilities needed in order to provide support for the modern software engineering process, I would certainly consider it a good idea to be prepared to use an automatic 83 => 9X translator as part of the conversion. Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/09/89)
From munck@chance.uucp (Robert Munck): > I think that many of the participants in this discussion thread are > missing an important point: the Ada effort is NOT primarily concerned > with the state of the art in programming languages, but rather that > of large-scale software engineering. I think otherwise: the effort is not to link Ada with the state of the art in programming languages, but to link Ada with the state of the art in software engineering. ^^^^^^^^^^^^^^^^^^^^ > These are two very different things, and it is to be expected that the > programming language chosen would be different. For example, language > stability is an important characteristic of this kind of s/w engineering; > the 10-year language upgrade period is on the same order of magnitude > (or even a bit low) as the time required for a big software project, > either DOD or commercial. Ada is intended to reduce life-cycle costs, > and changing the language every few years would have a large negative > effect on that. I see no reason why lengthy projects have to switch languages in mid-stream UNLESS they think it will help them out. Of course, given the existence of automatic translation facilities and the ability to exploit pragma Interface in both directions, this may in fact be the case. > What we have here is a failure of communication between research and > practicality. Universities and commercial research centers have very > little chance for experience in software projects that require hundreds > of programmer-years with large geographic and temporal distributions. > It is quite irrelevant to proclaim the powers of brand-new languages > until they have been used successfully in such large projects. Has > Has there been a C++ development of 500,000 lines or more that has > become a product in some sense and has been widely used? One that > has been developed by a prime/sub-contractors arrangement of a half-dozen > companies and passed on to another such group for maintenance? Well, > Ada can't claim many such either, but it was designed for that > kind of situation. The prime/subcontractor arrangement exists only in the realm of government contracting, and hence it would be unrealistic to expect an exact parallel in the commercial realm. However, there appears to be a substantial amount of C++ activity in industry, and some large products *have* been produced. I'm not sure of the exact line counts, but a quick query to comp.lang.c++ would undoubtedly produce all the statistics you can eat. There are a lot of negative things in C++, and a lot of the good stuff in Ada is not available in that language. The only two real advantages C++ can cite are: easy transition for C programmers, and multiple inheritance. The first is not something we SHOULD worry about; we don't need to provide C programmers with the ability to do all their favorite hacks. The second is a real problem, because the use of multiple inheritance is an important software engineering mechanism. It reduces the amount of code that must be written, and increases the speed with which products can be produced. By incorporating this mechanism into Ada, the sole argument for C++ becomes the unwillingness of C/C++ programmers to give up their hacking ways, and this is a problem we can successfully address. Bill Wolfe, wtwolfe@hubcap.clemson.edu
jcardow@blackbird.afit.af.mil (James E. Cardow) (10/10/89)
rcd@ico.ISC.COM (Dick Dunn) writes: >> ...Consider the ten to twenty year development cycle for large projects... >If you have a ten-year development cycle for a software project, you're >going to be producing obsolete software! You can't help it. Ten years is >just too long for anything tied to computers--the technology moves too >fast. >You've got to get software up and working, and performing at least some of >the needed functions *soon*. You also need it to be adaptable, so that it >can evolve as needs and technology change. I must admit that my comments were made with only my own experience in mine, that being large DOD sponsored projects that had developments spanning two to three computer generations. However, that is the primary Ada environment. In the military software support world we are for the most part just entering the support for JOVIAL systems. Having been responsible for "selling" Ada to the people attempting to prepare for "new" software, I'm convinced that injecting new technology especially evolving technology may very well be a cure more painful than the disease. Consider the problem in a real context. System software in the +100,000 lines of code, with supporting software at a 4:1 ratio. Add to that simulator software that must function exactly like the real thing. Now add unique hardware, especially processors. If the system were stagnant and the budget available the conversion to a new language would be simple (simpler?). But reality says the money for change is small, and the user demand for improvements is large. The changes come in modification of 10 percent of a unit here, 5 percent there. The only real opportunity is when major systems are effected, but that is rare. >What I'm getting at is that I think we're trying to address the wrong >problem. Rather than trying to solve "How do we deal with long development >cycles?" we should be solving "How do we shorten the development cycles?" >-- In the years I have spent chasing DoD software I have always worried about how to get it delivered closer to the expected date, the idea of shorter never occured to me. But, I'm changing roles now to teach software engineering and would greatly love to discuss ways to shorten the development cycle, or ways to inject new technology into old systems. If you have ideas on the subject within the context of large, complex systems or know of any work in these areas let me know. As a side note, Ada can be added to older systems. It takes convincing people that the benefits over the long run are worth the effort.
munck@chance.uucp (Robert Munck) (10/10/89)
In a previous article, I said: > ... the Ada effort is NOT primarily concerned > with the state of the art in programming languages, but rather that > of large-scale software engineering. > And in article <6699@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu replied: > > I think otherwise: the effort is not to link Ada with the state > of the art in programming languages, but to link Ada with the > state of the art in software engineering. > ^^^^^^^^^^^^^^^^^^^^ Does anyone else get the feeling that he's not LISTENING? It must be wonderful to have the leisure to reply at length to every posting, no matter what, but the replies should be based on what was originally written. -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP -- MS Z676, MITRE Corporation, McLean, VA 22120 -- 703/883-6688
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/11/89)
From article <73079@linus.UUCP>, by munck@chance.uucp (Robert Munck): > In a previous article, I said: >> ... the Ada effort is NOT primarily concerned >> with the state of the art in programming languages, but rather that >> of large-scale software engineering. >> % And in article <6699@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu replied: %> %> I think otherwise: the effort is not to link Ada with the state %> of the art in programming languages, but to link Ada with the %> state of the art in software engineering. %> ^^^^^^^^^^^^^^^^^^^^ > > Does anyone else get the feeling that he's not LISTENING? > It must be wonderful to have the leisure to reply at length > to every posting, no matter what, but > the replies should be based on what was originally written. It was. What you originally wrote (prior to the included material) was words to the effect that an effort is being made to link Ada with the state of the art in programming languages RATHER THAN the state of the art in software engineering, and this contention is what I took issue with. I submitted instead that the idea was to determine (as was the case with Ada 83) what language capabilities would best support software engineering practice, and move from there to specific language constructions. I see no basis for your contention that the state of the art in programming languages is being considered as the driving factor; what has changed is the state of the art in software engineering practice. This in turn requires new programming language support facilities. Example from Ada 83: Support shall be provided for data abstraction. Resulting constructs: generic packages, limited private types. Example for Ada 9X: Support shall be provided for object-oriented software development. Resulting constructs: classes, a multiple inheritance mechanism In each case we have a software engineering practice (data abstraction, object-oriented development) for which language support is required. Hence, it seems that the assertion that proposed changes are not being driven by software engineering requirements is not correct. Perhaps you know of a counterexample -- some proposal which is not related to support for software engineering practices. If so, please point it out directly. Bill Wolfe, wtwolfe@hubcap.clemson.edu
rcd@ico.ISC.COM (Dick Dunn) (10/12/89)
William Wolfe writes about Ada 9X and C++ > There are a lot of negative things in C++, and a lot of the good > stuff in Ada is not available in that language. The only two real > advantages C++ can cite are: easy transition for C programmers, and > multiple inheritance... This is a parochial view--something which is a perennial problem in the Ada community, and which has done a lot to inhibit interest in Ada, let alone acceptance of it. If you want folks to move to Ada, you can't get it to happen by just proclaiming the obvious, innate superiority of Ada and waiting for them to arrive in droves. You're going to have to try to understand why they're using C (or C++ or whatever they're using). There are many reasons; there are reasons not to convert to Ada; there is inertia. The harder you try to dismiss their reasons by working from your own viewpoints, the less credibility you have. (The reasons may not even be good ones! They still have to be addressed.) The credibility problems only get worse as you deal with more experienced software people. The longer people have watched and worked in software, the more alleged panaceas they've seen, and the more sure they are that there aren't any panaceas. Also, it's likely that they've worked in some truly awful languages and have produced decent software in spite of it, so they'll doubt that the choice of programming language is as important as you say. Finally, they'll have been watching the progress of Ada over the years and will have concluded that with the enormous amount of money thrown at it, if it were truly wonderful it would have really caught on by now. Part of what I'm saying is that you've got a marketing problem. Even if you have a wonderful product, you still have to sell it--you'll go broke if you just wait for customers to find you. And a lot of us aren't convinced that the product is all that wonderful anyway. [Wolfe finishing up on importance of multiple inheritance] > By incorporating this mechanism into Ada, the sole argument for C++ > becomes the unwillingness of C/C++ programmers to give up their > hacking ways, and this is a problem we can successfully address. This is flawed in several ways. The first is the attitude that C/C++ programmers have "hacking ways" somehow tied to the language, and that they can be corrected by setting them on the One True Path to Ada. Look, this is arrogant on the part of Ada folks and demeaning toward the C/C++ folks. You should be able to see that this sort of attitude won't cut it, *regard- less* of how much you like Ada or dislike C++! The arrogant and insular attitudes of Ada's adherents have done far more damage to the language than the lack of any feature could do. Also, the argument that you can just add multiple inheritance and win the battle is based on the assumption that C++ is now static, that it's not going to acquire any more useful features. I suspect strongly that this is a mistaken assumption. You had better assume that you are aiming at a moving target. If you want anything approaching a contemporary programming language, you're not going to get it by taking five years to get to where C++ is now, and then proclaiming you're done. The activity and adaptability of C++ is something you're going to have to address somehow if you're going to "compete" with it. Beyond that, if you just add a feature to Ada, it doesn't immediately become as useful as a feature that's existed in C++ for a while. There's a maturing period, during which people find the gotchas and evolve the paradigms. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/12/89)
From rcd@ico.ISC.COM (Dick Dunn): > Part of what I'm saying is that you've got a marketing problem. Even if > you have a wonderful product, you still have to sell it--you'll go broke if > you just wait for customers to find you. Many of the people who are being introduced to Ada (software engineering students) won't be in a position to change their organizations for a few years; in some cases, it simply takes time. Despite that, there are some major successes. For example, GTE is doing its future telephone network system (WINS) in what is expected to be over 20 million lines of Ada. We expect more. The primary limitation now (beyond inertia) is getting the bindings to things like SQL, and this is the subject of a lot of activity. The advanced second-generation optimizing compilers, along with the CASE environments (e.g., TeleArcs), are also coming on line just recently, and their impact is just beginning to be felt. > If you want anything approaching a contemporary programming language, > you're not going to get it by taking five years to get to where > C++ is now, and then proclaiming you're done. Of course not. We will take five years to get to everything C++ can do, plus many things (like multitasking and generics) it can't. > The activity and adaptability of C++ is something you're going to > have to address somehow if you're going to "compete" with it. Precisely why I advocate a shortened five-year revision cycle. > Beyond that, if you just add a feature to Ada, it doesn't immediately > become as useful as a feature that's existed in C++ for a while. There's a > maturing period, during which people find the gotchas and evolve the > paradigms. There are a lot of object-oriented languages and systems, many of which (e.g., Trellis/Owl) are more powerful than C++. The intent is to fully exploit the proof-of-concept work which has been done by the research languages rather than doing it ourselves. Once the concept is proven and debugged (and assuming that it's an important advance in software engineering technology), then it's time to move it into production. Bill Wolfe, wtwolfe@hubcap.clemson.edu
sakkinen@tukki.jyu.fi (Markku Sakkinen) (10/13/89)
In article <16192@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >William Wolfe writes about Ada 9X and C++ > >> There are a lot of negative things in C++, [...] >[...] >[Wolfe finishing up on importance of multiple inheritance] >> By incorporating this mechanism into Ada, the sole argument for C++ >> becomes the unwillingness of C/C++ programmers to give up their >> hacking ways, and this is a problem we can successfully address. > >This is flawed in several ways. The first is the attitude that C/C++ >programmers have "hacking ways" somehow tied to the language, and that they >can be corrected by setting them on the One True Path to Ada. Look, this >is arrogant on the part of Ada folks and demeaning toward the C/C++ folks. >[...] >Also, the argument that you can just add multiple inheritance and win the >battle is based on the assumption that C++ is now static, that it's not >going to acquire any more useful features. I suspect strongly that this is >a mistaken assumption.[...] The main problem of C++ is not that it would not have lots of good features (especially the newest release, 2.0). The problem is that it has such fundamental _bad_ features that will have no chance ever to go away: they should have been pruned in the first step from C to C++. Things like the pointer arithmetic certainly invite if not oblige C and C++ programmers to "hacking ways", or perhaps they invite hacker-style programmers to use these languages instead of more disciplined ones. Several other comments in Mr. Dunn's posting made sense, though. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland