From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!gatech!hubcap!billwolf%hazel.cs.clemson.edu From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) Newsgroups: comp.lang.ada Subject: Re: Ada 9X objectives Message-ID: <6658@hubcap.clemson.edu> Date: 2 Oct 89 18:00:23 GMT References: <20600007@inmet> Sender: news@hubcap.clemson.edu Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu List-Id: >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