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,92c39a3be0a7f17d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-14 11:49:28 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.stealth.net!204.127.161.2.MISMATCH!wn2feed!wn3feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc52.POSTED!not-for-mail From: "Mark Lundquist" Newsgroups: comp.lang.ada References: <9v57u1$mfb$1@nh.pace.co.uk> <9v74ov014bc@drn.newsguy.com> <9vb24v$7fg$1@nh.pace.co.uk> Subject: Re: Future with Ada X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Fri, 14 Dec 2001 19:49:27 GMT NNTP-Posting-Host: 204.127.202.212 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc52 1008359367 204.127.202.212 (Fri, 14 Dec 2001 19:49:27 GMT) NNTP-Posting-Date: Fri, 14 Dec 2001 19:49:27 GMT Organization: AT&T Broadband Xref: archiver1.google.com comp.lang.ada:17922 Date: 2001-12-14T19:49:27+00:00 List-Id: "Marin David Condic" wrote in message news:9vb24v$7fg$1@nh.pace.co.uk... > > 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? 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... > (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?) Well, GtkAda is an Ada binding to Gtk, and Gtk was (I think) meant to be Motif-alike for Linux, not designed as a cross-platform GUI (I could be wrong about this, I'm sure someone will correct me if that is the case :-). The point being, whatever can be said about GtkAda in this regard can also be said about Gtk. You wouldn't look to GtkAda to solve any problem that Gtk itself was not designed to solve. 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. As a matter of fact, a native GUI is the route that Java chose. They could have tried to isolate a "common denominator" subset and then translated it to Windows or Motif bindings, which would have resulted in the problems you mention. Instead they created a new native GUI that was supposed to look just as good on either platform. The early versions were a qualified success -- they did look "just as good" on either platform, that is to say, not very good -- but things are better with Swing. > > So I think there is a problem with getting large libraries of stuff > "standardized" in Ada. For the GUI stuff, you mean? > 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...) 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. > > 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. For foundational stuff (like collections), I think a de-facto standard would be OK only if it were perceived as "standards track". 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. At SIGAda '99 there was a paper by somebody who had done a study of U.K. defense firms who had essentially "not chosen Ada", and the study ranked the perceptions that contributed to that decision. Lack of a decent standard library ranked among the top three reasons. > > 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. Exactly. "Great environment to be had for the cobbling" just doesn't cut it. 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. > 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. Best Regards, -- mark -- -------------- Reply by email to: Mark dot Lundquist at ACM dot org Consulting services: http://home.attbi.com/~mlundquist2/consulting