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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,92c39a3be0a7f17d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-13 14:29:39 PST Path: archiver1.google.com!news2.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!uknet!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Future with Ada Date: Thu, 13 Dec 2001 15:13:18 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9vb24v$7fg$1@nh.pace.co.uk> References: <9v57u1$mfb$1@nh.pace.co.uk> <9v74ov014bc@drn.newsguy.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1008274399 7664 136.170.200.133 (13 Dec 2001 20:13:19 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 13 Dec 2001 20:13:19 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:17894 Date: 2001-12-13T20:13:19+00:00 List-Id: I'm basically with you here and have argued in this forum in the past that Ada should have more "standard" libraries. Some work is being done in the area of data structures - hopefully that much could become a de facto standard if not a de jure standard. I agree that it would be nice to have a large library of stuff just as does Java. In particular, some version of a standard GUI library of some sort. One of the problems with doing this is that Ada targets a whole slew of computers not all of which would have such a library make sense. Even for the platforms for which something like a GUI does make sense, you still might have problems specifying something that is portable and still makes reasonably good use of what is actually available on the given platform. Windows GUI stuff, for example, looks very different from what you get under Motif. Would a "standard" GUI library be able to work on both without restricting itself to some unacceptable subset of what is possible? Would Windows programmers/users want something that didn't look a lot like a typical Windows app? (GtkAda works in a variety of places, but it doesn't seem to look a lot like "Windows" when its on that platform. Is that going to be a handicap?) So I think there is a problem with getting large libraries of stuff "standardized" in Ada. To get it into The Real Standard, it would have to a) reduce itself to the lowest common denominators for the platforms on which it was possible and b) exist as an optional annex so it could be eliminated for platforms on which it was difficult or impossible to implement. (I don't see "b" as being a big problem - but there may be other opinions on that...) The other alternative - a de facto standard - might be a better choice. For example, you could have a "Windows-GUI" library and a "Motif-GUI" library that assumed the capabilities of a given platform and compiler vendors would have to come to some kind of agreement that if they were putting out a Windows targeted compiler that they would support the appropriate "standard" library. But this, in and of itself, has problems. It creates portability between compilers - but that's not necessarily in the interest of the vendors and may not be that interesting to the consumers. It certainly doesn't provide portability across platforms - which might be of varying levels of interest to the consumers. Besides, no matter how much discussion there is around here about the need for semi-standard libraries, we never seem to hear anything from the vendors indicating that they are at all amenable to the idea. If they won't get behind it, the issue is dead. We already have lots of libraries of Ada code available for the cost of a download, but that leaves the end-user bumbling around, cobbling together a development environment of dubious quality and consistency. Not to mention that it isn't a "standard" then - or maybe its in the mode of: "Standards are such a wonderful thing that everyone wants one of their very own!" :-) So I'm not sure how to get there other than by doing what is happening in one small corner of this newsgroup with respect to the idea of an Ada Standard Components Library: If a group of interested parties gang up on a given problem space and produce a reasonably good library that they are willing to put in the public domain, it might stand a chance. If there is some reasonable level of consensus that it is "The Right Thing" or "Good Enough" and finds some following, then *maybe* the vendors will get behind it and distribute it. But that's a big "maybe". If Ada were owned by Sun or Microsoft, it might get the funding to produce some large standard libraries for at least the platforms targeted by either of those giants. If Ada had not been "abandoned" by the DoD, it is conceivable that they might have thrown some big $$$ at developing some "standard" libraries. (Indeed, they were the source of some of the numerous, disparate, bits-and-pieces libraries that are out on the Internet today.) But without the deep pockets and/or the will/direction to Make It So (expressed by the vendors and/or SIGAda?) I don't see much chance of it happening. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Mark Lundquist" wrote in message news:oN5S7.47886$Yy.536849@rwcrnsc53... > languages. The big library philosophy won (and if I may add, rightly so > IMHO). I feel it will be best for Ada if the maintainers of the language > lose any hangups they may have over this (I don't know if they have any or > not), e.g. any lingering sensitivity to 80's criticism of Ada as "too big" a > language. People are used to thinking of a "core language" + "standard > library", and they expect the library to be big. They understand the > difference between that and a huge core language. >