byrne@arecibo.aero.org (04/15/91)
-Message-Text-Follows-
I have not seen any discussion on the Ada 9X draft Mapping Document in
this group. Is there another group dedicated to informal 9X rapping as opposed
to the formal comments to the AJPO?
Or does everyone thinks it perfect? 8-)
Dan J. Byrne jls@rutabaga.Rational.COM (Jim Showalter) (04/17/91)
> I have not seen any discussion on the Ada 9X draft Mapping Document in >this group. Is there another group dedicated to informal 9X rapping as opposed >to the formal comments to the AJPO? >Or does everyone thinks it perfect? 8-) Well, personally I think it's overkill. The current documents are in a very sketchy state, and they are already large. By the time they are transmuted into real modifications to the LRM, the LRM will be twice as large as it already is. I'm personally a big fan of subprogram and package types. I also favor getting rid of the idiot special-cases (e.g. latter declarative items, etc) that make learning the language more difficult than it needs to be. And I'd like a few notational conveniences like "return...when" and "raise... when". The problem is, MY list isn't necessarily the same as YOUR list: and our aggregate lists may not include some other person's wish list. The aggregation of EVERYBODY'S lists results in a huge shaggy baggy monster of a language revision. What should have been a very quick, very restricted effort to triage the top 20 complaints has mushroomed into accomodating just about everybody. The question we ought to ask ourselves at this point is: what problem are we really trying to solve? Are we trying to fix some defects in the original language definition? Fine--by all mean let's do so. Or are we actually trying to permute Ada into some radically new language, like, say, C++ or Eiffel? If so, WHY? The putative merits of such languages for large complex systems are not well-established. I think they're largely a fad. Do we run off in eleventy-seven different directions trying to make Ada be all things to all people (something it was never EVER intended to do), or do we stick with the knitting? Focusing on finding out WHY many compiler vendors have crappy tasking applications is probably a far better way to deal with performance issues than is dragging in a whole new, untried mechanism. If we're going to make the language be all things to all people, shouldn't we throw in inferencing for the AI folks, multiple inheritance for the inheritance weenies, dynamic typing for the terminally confused, etc etc etc? Hrmph. -- * The opinions expressed herein are my own, except in the realm of software * * engineering, in which case I borrowed them from incredibly smart people. * * * * Rational: cutting-edge software engineering technology and services. *
jls@netcom.COM (Jim Showalter) (05/09/91)
>James Thiele >Disclaimer: >Nobody on this group thinks that a C program written by a great C programmer >could be better than an Ada programm written by a lousy Ada programmer. >I do, I know you don't, so don't bother flaming me. Now now--let's not jump to conclusions. I've seen good C and wretched Ada, no doubt about it: nobody ever claimed otherwise. What IS claimed is that if you pull a listing at random from a pile of C programs and a listing at random from a pile of Ada programs and compare them, the smart money bet is that the Ada program is better engineered.
jordan@aero.org (Larry M. Jordan) (05/10/91)
Jim Showalter says: >...What IS claimed is that if you pull a listing at random from a >pile of C programs and listing at random from a pile of Ada programs >programs and compare them, the smart money bet is that the Ada program >is better engineered. In theory I agree with this. In practice, gained from two large DoD funded efforts, this is not yet the case. I've seen many thousands of lines of poorly engineered Ada. It is refreshing to find that textbook example of a generic, but it is rare.
tedg@apollo.HP.COM (Ted Grzesik) (05/10/91)
In article <1991May9.055530.1516@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >Now now--let's not jump to conclusions. I've seen good C and wretched Ada, >no doubt about it: nobody ever claimed otherwise. What IS claimed is that >if you pull a listing at random from a pile of C programs and a listing >at random from a pile of Ada programs and compare them, the smart money >bet is that the Ada program is better engineered. About the worst Ada code I've seen is by someone that was obviously a prior C programmer. In general, I have observed code that was written in the syntax of one language, but used the style of another language. I worked on a large Ada program (an Ada compiler, to be precise) that used lots of UNCHECKED_CONVERSION and UNCHECKED_DEALLOCATION. Once you've introduced these two routines into your program, you're just writing fancy C code. Using these routines indicates either a flaw in your design or a limitation of the Ada language. Usually, it's a flaw in the design. My $0.02 Ted Grzesik Massachusetts Language Lab Hewlett-Packard Company tedg@apollo.hp.com Chelmsford, MA (508) 256-6600 x5959 "Civilization is the limitless multiplication of unnecessary necessities." -- Mark Twain (Samuel Clemens)
eachus@largo.mitre.org (Robert I. Eachus) (05/15/91)
In article <5176c098.20b6d@apollo.HP.COM> tedg@apollo.HP.COM (Ted Grzesik) writes:
I worked on a large Ada program (an Ada compiler, to be precise) that used
lots of UNCHECKED_CONVERSION and UNCHECKED_DEALLOCATION. Once you've
introduced these two routines into your program, you're just writing fancy
C code. Using these routines indicates either a flaw in your design or a
limitation of the Ada language. Usually, it's a flaw in the design.
Not really. What indicates a problem is when UNCHECKED_CONVERSION
or UNCHECKED_DEALLOCATION appears in a package specification, rather
than hidden in a body, hopefully a procedure body. For years, I have
called UNCHECKED_CONVERSION in a library package specification
UNCHECKED_PERVERSION, since it usually destroys the data independence
of both input and output types. The cost of putting the instantiation
in the body of a procedure is small (and on a good compiler it will
just be the cost of writing additional code, not executing it), but
the difference in portability can be night and day.
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...