jcardow@blackbird.afit.af.mil (James E. Cardow) (10/04/89)
I have to agree with Mr Wolfe, a two year update cycle would cause havoc with the language and the organizations attempting to support the software already developed or nearing the end of development. The support organizations for large, real-time software systems (the original target of Ada) would like nothing more than to have the latest and greatest improvements in their software and support tools. The problem is, minor changes cause major problems.Consider the ten to twenty year development cycle for large projects. Compiler vendors (not to mention) compilers enter and exit the market over that period. The software and the compiler must then be supported by someone else. The ten year span is most likely too long. The additional time to effectively propagate the change and maneuver through the bureaucracy stretches the time to closer to 15 years. With that time frame, too many technically sound improvements are ignored. Those of us is support painfully realize the difference 15 years of technology change make. As far as what changes should be considered, the first step should be an evaluation of the features of "research" languages. The very features that make them attractive are probably the most desired in changes to other languages. Inheritance as handled by C++ would certainly seem to be a prime candidate. There is usually a reason why those features make the language attractive, not considering and incorporating them is foolish. Changes to Ada 83 are needed. The change frequency should be reevaluated. The healthy discussion over which change to include is outstanding. Too bad the support community is not making a greater input, they will live with the results long after the developers move on to newer ideas.
ted@nmsu.edu (Ted Dunning) (10/05/89)
In article <1373@blackbird.afit.af.mil> jcardow@blackbird.afit.af.mil (James E. Cardow) writes:
...
As far as what changes should be considered, the first step should be an
evaluation of the features of "research" languages. The very features that
make them attractive are probably the most desired in changes to other
languages. Inheritance as handled by C++ would certainly seem to be a prime
candidate. There is usually a reason why those features make the language
attractive, not considering and incorporating them is foolish.
how do you add the primary feature of scheme which is parsimony to ada
whose salient characteristic is obesity?
in the formal semantics of scheme, the abstract syntax of scheme is
_6_ lines long. and yet this language has considerably _more_ power
than ada in many respects.
how do you ADD this to ada which doesn't even yet have a formal
semantics?
--
ted@nmsu.edu
remember, when extensions and subsets are outlawed,
only outlaws will have extensions or subsetsrcd@ico.ISC.COM (Dick Dunn) (10/07/89)
jcardow@blackbird.afit.af.mil (James E. Cardow) writes about the problems in shortening the Ada language update cycle. His points were good, yet I was left with the feeling that there was something wrong underneath. I finally decided that it's this: > ...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. 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?" -- +---------+ Dick Dunn rcd@ico.isc.com ico!rcd (303)449-2870 | In this | 4th annual MadHatterDay [10/6/89]: | style | Madness takes its toll |__10/6___|
eachus@mbunix.mitre.org (Robert Eachus) (10/13/89)
In article <16176@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >jcardow@blackbird.afit.af.mil (James E. Cardow) 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. In many cases the schedule is determined by something other than the software, such as the Space Shuttle. (And the only reason that software wasn't on the critical path was the problems with the tiles, but I digress.) Or any new commercial jet aircraft like the 7J7, or military projects like the Advanced Tactical Fighter... Software schedules for such large, long duration projects will include many builds and tests before the actual aircraft is flown. Again, to use the Space Shuttle as an example, the filght software was extensively tested (and frequently crashed) in various simulators before the Shuttle was ever flown, and the Shuttle was flown as a glider several years before it was ever launched from the cape. Each software build may have a short schedule, but you need the software from build 1 to still mean the same thing when build 27 (or build 103) gets tested for the first time in the air, and when build 34 goes into the first production aircraft. Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...