scc@cl.cam.ac.uk (Stephen Crawley) (09/29/89)
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
baur@venice.SEDD.TRW.COM (Steven L. Baur) (10/03/89)
in article <929@scaup.cl.cam.ac.uk>, scc@cl.cam.ac.uk (Stephen Crawley) says: > Posted: Fri Sep 29 13:41:17 1989 > > Well how come ADA seems to be largely irrelevant outside of the defense > sector? It is not really. But current Ada compiler technology produces large slow code. Given mature languages like "C", there should not be much incentive currently, to use Ada. What is most interesting is that Ada is not particularly acceptible for D.O.D. applications either. (Some background first) I produced a Heterogeneous Interprocess Communications library for Ada that was used for the Army FAAD (Forward Area Air Defense) project (and might well be used on future contracts). FAAD is part of a five-part Army contract to computerize the entire battle- field. The MCS project (Maneuver Control System - part of the same system FAAD is to run in) was fielded first, and runs on a system with MC68010s, bubble memory, and a plasma display. It uses a specialized version of Ada developed by Ford Aerospace Corp. that has needed properties for implementing the system. The extensions to Ada that Ford wrote are incompatible with any Ada standard. I emphasize this point because DOD has published data about Ada-using contracts and has emphasized (among others MCS), and I know MCS does not use "true" Ada. (Other TRW Ada using projects depend on system dependent facilities of the local Ada, with portability being thrown out the door). > ... ADA 9x will be 10 - 15 years out of date. Agreed. But I don't have to like it. > ... > 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. You may be wrong on that. We see the limitations of ADA83 too clearly. (I hope you're wrong on that -- I'm a TRW stockholder). > ... There are two remaining things: Ford Aerospace is rewriting X-Windows because it takes up too much core and is too slow (for the MCS project). The Heterogeneous IPC effort was an order of magnitude more difficult to implement in Ada than in "C". steve (baur@venice.sedd.trw.com)
rang@cs.wisc.edu (Anton Rang) (10/03/89)
In article <30@venice.SEDD.TRW.COM> baur@venice.SEDD.TRW.COM (Steven L. Baur) writes: >in article <929@scaup.cl.cam.ac.uk>, scc@cl.cam.ac.uk (Stephen Crawley) says: >> Posted: Fri Sep 29 13:41:17 1989 >> >> Well how come ADA seems to be largely irrelevant outside of the defense >> sector? > >It is not really. But current Ada compiler technology produces large slow >code. Well, I'm not an Ada person, but current Ada compiler technology does *not* produce large, slow code. I used to use the Telesoft VAX/VMS Ada compiler; even without global optimization, it produced code comparable to the other VMS compilers (which are all fairly mature and produce excellent code). I haven't used many other Ada compilers, but VAX Ada also appears to do a pretty good job of code generation. > Given mature languages like "C", there should not be much incentive >currently, to use Ada. C is mature? There isn't even a standard for it yet! Besides, it is missing a LOT of features very useful for large projects: nested packages, information hiding, etc. It doesn't even have nesting in the namespace (writing two functions called "sort_array" generally leads to trouble). > [ a few experiences with Ada use deleted ] >The Heterogeneous IPC effort was an order of magnitude more difficult to >implement in Ada than in "C". Is this because of the language itself, or because it requires a different programming methodology? The learning curve for Ada is pretty steep, and I suspect that it's even worse for managers of large projects. Did the managers and programmers have experience with both Ada and C before the project was started? I'm not saying that Ada is universally better than (or even as good as) C, but I've run into a lot of cases where using C was a big headache (usually due to the lack of nested procedures/modules). +----------------------------------+------------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | | University of Wisconsin--Madison | | +----------------------------------+------------------+
rcd@ico.ISC.COM (Dick Dunn) (10/05/89)
rang@cs.wisc.edu (Anton Rang) writes: >...scc@cl.cam.ac.uk (Stephen Crawley) says: > > Given mature languages like "C", there should not be much incentive > >currently, to use Ada. > > C is mature? There isn't even a standard for it yet!... This is a cheap shot. C has been developed in the natural sequence, namely "try it first, then standardize it." The fact that Ada was standardized before there was even an honest working compiler for it--let alone any useful experience with the language--is such a massive act of monstrous stupidity that even now, years later, I (and most other programming-lang- uage folks) have trouble believing it was done that way. The standardization of C also followed an arduous, but very open, pro- cess...in which the issues surrounding the language were exposed to serious (and sometimes seemingly endless!) debate. The Ada standard, on the other hand, was lambasted as ill-advised, ill-considered, premature, etc., on various counts and in various ways by leaders of the profession and by at least one professional society (ACM). The response from the DoD was, essentially, "Thank you for your concerns. Damn the torpedoes; full speed ahead." The Ada standardization process is something to be ashamed of. The refusal (and inability) to let the language evolve is precisely the reason you're seeing comments in this newsgroup that Ada is behind the times and falling farther behind. As for maturity...C IS "mature" in the sense of being heavily-used and well-understood for a long time--not "mature" in the sense of having a well-established, hidebound bureaucracy to protect it. >...Besides, it > is missing a LOT of features very useful for large projects: nested > packages, information hiding, etc. It doesn't even have nesting in > the namespace (writing two functions called "sort_array" generally > leads to trouble). Information hiding happens (and is intended to happen) at the "module" (which essentially means "source file") level in C. Frankly, experience has indicated that this one level of nesting and hiding hasn't caused as much trouble as people outside C might think. It's simplistic, perhaps, but it's also simple. Nested procedures are more expensive, particularly in the face of procedure variables--which are both useful and commonly used in C. -- +---------+ Dick Dunn rcd@ico.isc.com ico!rcd (303)449-2870 | In this | 4th annual MadHatterDay [10/6/89]: | style | A Thousand Points of Madness |__10/6___|
ok@cs.mu.oz.au (Richard O'Keefe) (10/05/89)
In article <16160@vail.ICO.ISC.COM>, rcd@ico.ISC.COM (Dick Dunn) writes:
: This is a cheap shot. C has been developed in the natural sequence, namely
: "try it first, then standardize it." The fact that Ada was standardized
: before there was even an honest working compiler for it--let alone any
: useful experience with the language--is such a massive act of monstrous
: stupidity that even now, years later, I (and most other programming-lang-
: uage folks) have trouble believing it was done that way.
Believe it. How did you think COBOL was produced?
The BSI/ISO committee working on a Prolog standard aren't quite that
silly, but they have consistently taken the attitude "never mind what
people happen to be _using_ already, it's what we like or don't like
that counts". (Would you believe that the error handling construct
is called "block"?)amull@Morgan.COM (Andrew P. Mullhaupt) (10/07/89)
> > > > C is mature? There isn't even a standard for it yet!... > > This is a cheap shot. C has been developed in the natural sequence, namely > "try it first, then standardize it." The fact that Ada was standardized > before there was even an honest working compiler for it--let alone any > useful experience with the language--is such a massive act of monstrous > stupidity that even now, years later, I (and most other programming-lang- > uage folks) have trouble believing it was done that way. > > It is impossible to take a cheap shot at the lack of standardization of C. C has been developed along the lines of; get something working and lists the bugs as features later. When it turns out you have to turn your head inside out to cope with the goo that passes for 'traditional' C source, you excuse the miscreants because when they were growing up, that piece of code could only be done by machine specific finesse, and now they write all their goo likewise so the awful parts don't stick out so much. C is the only widely used compiled language for which a program can (in principle) be constructed so that: 1. The program is syntactically correct. 2. For every input, the program eventually halts. 3. It is not possible to determine from the sources what logical relation the input bears to the output. (In the jargon of computer science, rules for proving partial correctness cannot be given for all of the C language. The commonly used unbound pointer is the culprit here.) Let's not get into the stupid issues, (what order should bytes appear in a word in), and the glaring unreadabilities, (int* a,b,c; often written, always a miscue!), and the downright ugliness of this woeful UNIX stepchild. Let's talk about what C does to otherwise good programmers. I am the first to admit that working in an ad-hoc language corrupts your ability to program effective readable code. I was once a very sharp Pascal programmer (on the grounds that ALGOL 68 was never really coming). After about one year of exposure to the insidious APL language and first went my FORTRAN skills (the least structured are the first to go) but recently I have been stuck for syntax of case statements, and other simple Pascal constructs, which do not need to be remembered, but can be reconstructed from the principles of the language. I'm starting to remember little tricks and devices as opposed to reasoning about code constructs. Having been exposed to both APL and C, I can definitely state that the fewer letters in the language name, the more ad hoc the syntax is. There are no cheap shots at C; it deserves all the flames it gets, and much more. If C is a mature language, let's ask: "Does this mean we won't have to put up with it much longer?" Oh well, wishful thinking, I guess. Later, Andrew Mullhaupt Disclaimer: Any opinions expressed here are entirely my own. Often I wished more people would admit to themselves what a hodgepodge C is.