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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38fc011071df5a27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-29 15:14:55 PST Path: news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!sjc70.webusenet.com!news.webusenet.com!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread2.news.atl.earthlink.net.POSTED!not-for-mail Message-ID: <3F78AECE.1080900@noplace.com> From: Marin David Condic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (OEM-HPQ-PRS1C03) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: How to get a =?ISO-8859-1?Q?=BBConventional_Ada_Library=AB?= =?ISO-8859-1?Q?_=28Was=3A_Ideas_for_Ada_200X=29?= References: <6a90b886.0305262344.1d558079@posting.google.com> <3ED4A94C.2020501@noplace.com> <3ED6A852.75AC0133@adaworks.com> <3ED74ED3.4020505@noplace.com> <3ED7C8C5.3070902@cogeco.ca> <3ED826BB.9010509@noplace.com> <3F61BA28.3060507@crs4.it> <3F6205B8.3070402@attbi.com> <3F6316DC.7080106@noplace.com> <3F743AE7.5050305@noplace.com> <3F74E2A6.6020907@comcast.net> <3F75A5E3.6040505@noplace.com> <3F761DC6.3050801@comcast.net> <3F76F66C.80009@noplace.com> <3F7720D3.6020609@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 29 Sep 2003 22:14:50 GMT NNTP-Posting-Host: 209.165.28.132 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.news.atl.earthlink.net 1064873690 209.165.28.132 (Mon, 29 Sep 2003 18:14:50 EDT) NNTP-Posting-Date: Mon, 29 Sep 2003 18:14:50 EDT Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: news1.google.com comp.lang.ada:222 Date: 2003-09-29T22:14:50+00:00 List-Id: Robert I. Eachus wrote: > > We (meaning the ARG and compiler vendors) have been getting better at > that. But even with unlimited money, standards move very slowly. > It isn't just money. Its that a standard that changes once a week isn't really much of a standard, is it? ;-) But at the end of the day, if there were a library that existed as a "reference implementation" and it was maintained under the watchful eye of the ARG & Vendors and it was distributed along with most vendor's compilers, you'd have a mechanism for dealing with problems like lack of a "standard" square root routine as these things came up. I don't think anybody wants to see the syntax and semantics of the Ada language itself change on a quarterly basis, but a library could easily be released on a schedule like that and so long as it has some mantle of "officialness" and is distributed with most compilers, it becomes a mechanism for plugging up holes as they are found. Its not that the job wouldn't still require some careful consideration regarding exactly what got into the library, what sort of specifications would be adopted and what the semantics should be for the implementations. You'd probably want the ARG/Vendors to come to some agreement about the intent of a given package and what its spec should look like. You'd also want them to do some "due diligence" to look over whatever has been produced to determine that it was of acceptable quality. Beyond that, you could probably leave lots of the details in the hands of whoever is actually doing the implementation. (That's typically how software gets built in "real world" projects anyway, right? And I think we're talking essentially about commissioning the development of a single body of software to be shared by all interested parties rather than the development of a "standard" that would be implemented by many interested parties.) So what I'm thinking about is a bit of a different situation than what the ARG and Vendors are typically doing with the standard. Rather than debating it endlessly and struggling to write formal, verifiable standards, they'd be in the business of outlining in broad-brush strokes what they thought they wanted for some specific subsystem and then reviewing the end-product to see if it met their intent sufficiently to warrant being released. There are two catches here: One is agreement on the part of the ARG and Vendors that something like this should be done & accepted as part of "Ada" in some manner. (Its got to end up in most compiler distributions or its just another library dangling around on the Internet somewhere.) The other problem is to get people to develop the actual code once the Keepers Of The Eternal Flame have decided that a given thing is worth inclusion in the library. I think both these issues could be resolved. #1 is just the willingness of the ARG & Vendors to go down that path. (Yes, it would mean diverting some attention to it, so it isn't without cost. But if its worth having, its worth spending some $$$ to get it, right?) #2 is trickier, but we've seen in the past a variety of volunteer efforts in a number of settings that have attempted to do parts of this job. That means there are people out there willing to do the work, but they perhaps need some direction and incentivising in order to accomplish specific goals. I think it could be done with a little creativity. Get #1 resolved and somehow, some way, #2 can be brought about. > The other thing that you have to remember is that the programming > culture around Ada had not developed when the original ANSI standard was > produced. I was surprised, and so were a lot of other people, at how > the Ada culture developed in a way that was loathe to use almost > anything that wasn't in the standard. > Sure. But this is not a goal in and of itself. Its more a symptom. (And it may be due to Ada over-selling the case for "portability". Realistically, most programs never port to a different compiler or platform.) I think most Ada users would be thinking along the lines of: "If its in the standard, then I know what it does and I can count on it being there. If its not in the standard, I may not be portable to a different implementation and I may not be able to find out what it does without difficulty." That doesn't automatically translate into a "Must Be In The Standard" requirement. If Ada had a library that was maintained as a reference implementation and distributed with most compilers, in some ways this would be even *more* "Standard" than something in the ARM. The ARM allows lots of wiggle room that can result in significant differences between implementations. If you had a reference implementation of a library, you'd have far less divergence in behavior between implementations because each vendor's realization of the library starts from a common code base. That, coupled with the fact that the end user is (presumably) getting source code for the library under some reasonably non-restrictive license and I think you'd see little difference in how the library would be treated compared to how the standard is treated. > Even more surprising was the antipathy towards using representation > attributes and other Chapter 13 features. By the time the 9X effort was > underway, no one was really surprised by the number of change requests > that basically translated to, "We want to do unchecked conversions, but > our coding standards don't allow us to use Unchecked_Conversion." > I remember back in the olden-days of Ada83 how various lynch mobs formed up around some of the vendors, all of them carrying torches and pitchforks and chanting "Give Us Chapter 13 - Or Else!" :-) Chapter 13 is absolutely essential for embedded system development and this was, of course, the original intended market for the language. Ada really succeeded in alienating that market who pretty much all went out and bought C compilers because they could at least get their job done and it didn't cost them their first born sons in order to get a working compiler. Having successfully driven away the original intended market, the ones that were left didn't care much about Chapter 13. But not to worry - Ada succeeded in finding enough other ways of alienating the remaining crowd that lack of Chapter 13 wasn't necessary to help it snatch defeat from the jaws of victory. And probably because Ada had concentrated on convincing its users on the virtues of portability and type safety, it actually might have created the climate of fear that lead to coding standards forbidding things in Chapter 13. Its a shame that the case got over-sold to the point where people wanted to chop out a critical part of the language rather than take a more practical view that aimed to use the features judiciously when and where it made sense. The amazing thing is that Ada has had lots of die-hard fans who were convinced of the inherent goodness of the language. But despite that following, the language somehow managed to squander the capital by failing in its realization of the vision. Lots of things could be cited as missed opportunities. Initial poor quality of compilers, outrageously priced compilers, too ambitious a language for the hardware available at the time, too "big" a language for some of the smaller microprocessors it might have targeted, lack of cross-compilers for embedded hardware, etc. I'm sure we could go on but the real question ought to be "How do we take what we still have and parlay that into a substantially bigger market?" I think the answer to that question is to focus in on Customer Needs. What is it that the average programmer in a given domain needs to get his job done? What are the important factors in satisfying that user? Rather than looking at this or that syntactic/semantic element of the language and asking if it can be enhanced or otherwise made "better", the focus should be on "If we do this thing to the language, how does that help the Ada user to get his job done faster, better, cheaper?" IMHO, most language changes might fall into the category of "This would be nice to have if you have unlimited resources to implement things, but I could find a reasonable way to program without it..." Whereas a library of useful tools that gave me lots of extra leverage because I won't be re-inventing the wheel would likely start making a much bigger impact on how useful the language would be for me. The opportunity is there. We have yet to see if Ada can figure out how to exploit it. > > I don't know if Rational did modify their compiler. But the point is > that Rational, and their customers, thought that limiting the use of > Unchecked_Conversion was a good thing. Even in this case, where as I > said, in Ada 95, one package would be a child of the other, so no > conversion, checked or otherwise, would be required. > > "Limiting the use..." probably is a good thing - but a limiting that should be done in the best engineering judgement of the end-user. I guess I sometimes resent a compiler trying to save me from myself when I am insisting "No, I *really* meant to do that and I *know* what the consequence is, so please get out of my way and stop trying to 'help' me!" Sometimes Ada gets too picky for the end-user's own good. But then again, I can't think of a language I've ever used that *didn't* get in my way sometimes, so maybe this is just normal. Still, for Ada's original intended audience, I think it was important not to take such an extreme approach to items like Unchecked_Conversion. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m c o n d i c @ a c m . o r g "All reformers, however strict their social conscience, live in houses just as big as they can pay for." --Logan Pearsall Smith ======================================================================