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-14 13:21:00 PST Path: archiver1.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: Fri, 14 Dec 2001 15:39:36 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9vdo2a$9h3$1@nh.pace.co.uk> References: <9v57u1$mfb$1@nh.pace.co.uk> <9v74ov014bc@drn.newsguy.com> <9vb24v$7fg$1@nh.pace.co.uk> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1008362378 9763 136.170.200.133 (14 Dec 2001 20:39:38 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 14 Dec 2001 20:39:38 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:17930 Date: 2001-12-14T20:39:38+00:00 List-Id: "Mark Lundquist" wrote in message news:bJsS7.49746$ER5.625524@rwcrnsc52... > > You're right, AWT/Swing account for a large part of the JCL. And > cross-platform GUIs are a big hairy rat's nest, for the reasons you mention. > But I think there's plenty a standard Ada library could focus on that's more > fundamental than GUIs. I'm interested in things that help with programming > the "under the hood" stuff, and I'd just as soon let the GUI stuff alone for > the time being... > True. I could imagine a (semi)standard library that included basic data structures, various math libraries, text manipulation, possibly interesting tools for multitasking, etc. Things like that could be done strictly in Ada syntax and a reference implementation could be built that the vendors would perhaps have to adapt for the peculiarities of their compiler. The problem is that most of the real big leverage items start to become things that intersect with the OS or machine peculiarities. I could imagine things like a GUI, file management stuff, networking, etc., all being much more useful than data structures and math, but then there is some question about how it could be done in such a way as to be "standard" yet not end up unimplementable (or simply difficult to implement) on most platforms where the capabilities exist. And then its a problem to consider that a handful of dedicated Ada fanatics aren't likely to be able to produce something that big in a reasonable timespan and offer the vendors a reference implementation. You'd have to provide those sorts of things as a "Here's the Unix variant and here's the Windows variant and here's the Mac variant...." It may not be impossible, but the bigger the scope gets, the less likelihood it would get done with volunteers. So I could see concentrating on the kinds of "under the hood" features you mention as A Good Start. But would that alone make Ada competitive with MSVC++ or Java? > > I think any true cross-platform GUI (regardless of implementation language) > is not going to take the approach of building on top of Windows and Motif > bindings and lifting out a "common denominator" subset. Rather, it would > bypass the Windows and Motif widget sets and go all the way down to pixels. > Its internal architecture might have pervasive capabilities for emulating > Motif of Windows LAF as much as possible, but it would be a stand-alone > native GUI for running inside Windows frames or X-Windows clients. > Yeah. That's an angle I didn't bring up. I could see that as a potential solution, but its a dog with different fleas. You'd still have to do some version of saying "Here's your Unix variant, your Windows variant....." and it doesn't lend itself to the notion of a reference implementation that the vendors can just pick up and tweak. It also suffers some from the problem of having an entirely different look-and-feel than what a native-mode application might produce. Netscape is a kind of thing like this - it works fine, but it doesn't look-and-feel quite like a native Windows app. Would end-users accept having their word processor and spreadsheet look different from the rest of the OS environment just because they were built from the Ada Standard GUI Thingamabob? Maybe - it is not clear they would reject it, since a lot gets done with Netscape. I mentioned elsewhere the notion that if there were some flavor of an XML doohickie out there for Ada that it might be possible to use that as the basis for a portable, standard GUI. So basically, I'm not against the idea - just that I have some doubts about how easy it would be to get it incorporated as a "standard" feature and about how it might be met by the developer & end-user communities. > > > > > So I think there is a problem with getting large libraries of stuff > > "standardized" in Ada. > > For the GUI stuff, you mean? > For the GUI stuff - and for other things. Obviously, the less work you demand of the vendors to incorporate something, the more likely it is to get in there. Self-contained Ada libraries would be easier to get adopted - but it is a long way from a shoe-in. Even if you gave the vendors a totally free shot at a reference implementation and put it in the public domain, they might be reluctant. Even if its free, they still have to answer telephone calls about it and make sure it works in their environment. The further away you get from Ada-only-reference-implementation (do we have a word for this???) the harder it would be to get it adopted. Unless, of course, someone with really deep pockets simply paid to have it implemented and started supplying "The Compiler" (free, naturally :-) that forced everyone else to play catch-up. > > Of course there is a standard library today, specified in the Annexes -- > it's just meager, that's all. But that standard library is not monolithic; > the Predefined Language Environment (Annex A) is required, and the parts of > the standard library specified in the specialized needs annexes are > optional. I view things like collections as foundational and not dependent > on platform capabilities, so they should go into the predefined environment. > If there were ever a GUI, it would be a special needs annex. > Well, yeah, but I still think you'll discover there is resistance to that notion. Should some rather large GUI library get incorporated into the standard as an annex? (Or some other library of sufficient complexity and not a Native-Ada-Reference-Implementation) I think you'll find resistance to that because of the difficulty of writing up the annex in a rigorous enough way that it can be tested for conformance. Better to shoot for something that is more of a de facto standard because most compilers have it available with possibly some variance in quality, behavior or completeness. > > For foundational stuff (like collections), I think a de-facto standard would > be OK only if it were perceived as "standards track". > I'd settle for most vendors supplying it and skip actually getting it into the ARM. As I said above, this could be difficult. > The "package" of a great core language plus a great standard library is just > so much more compelling than that of a great core language plus a lot of > random freeware (a point you make below...). It's the total package, not > just the core language, that people look at when making a decision. > Yup. And look at things like MSVC++ and Java to see what the competition has available. That's what Ada would be measured against. And the problem is there is a lot more in those implementations than simply things that could come from Ada-Only code - especially if it is developed by volunteer effort. > > Exactly. "Great environment to be had for the cobbling" just doesn't cut > it. > You need to get it as a fully integrated kit so that its just "there" to be used. If it were (semi)standard, that makes it so much the better so that books can be written about it, training can be found for it, and developers can move from one project to the next and not be stuck relearning a whole new set of cobbled-together tools. (Either that, or the Deep Pockets answer would have the same effect.) > For the vendors to get behind such an initiative would take one of two > things, either (a) the paying user community clamoring for it, or (b) > incorporation into the standard. In practice this amounts to much the same > thing, since (a) will have to hold true for any candidate for (b) :-). In > fact, (b) in and of it self has much less leverage since the dropping of the > Ada "mandate", which "statutory validation" was designed to support. In > theory, a vendor could say "we don't support the full standard; big whoopie > ding," although even with an attitude like that toward an expanded standard > library, the presence of a freely redistributable/modifiable reference > implementation would probably go a long way towards making it a no-brainer > for a vendor. > Agreed - but as I said above, there are problems with getting something like this into the ARM and even if its free, the vendors may still not adopt it for a variety of reasons. > > 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 > > I think that's actually a pretty good way to get there. > It is A Good Start and might help to make Ada a more attractive language to many users. But it is still a long way from creating competition for things like Java. 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/