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 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-19 09:41:33 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: Wed, 19 Dec 2001 10:00:33 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9vqa2k$8rc$1@nh.pace.co.uk> References: <9v57u1$mfb$1@nh.pace.co.uk> <9v74ov014bc@drn.newsguy.com> <9vb24v$7fg$1@nh.pace.co.uk> <9vdo2a$9h3$1@nh.pace.co.uk> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1008774036 9068 136.170.200.133 (19 Dec 2001 15:00:36 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 19 Dec 2001 15:00:36 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:18100 Date: 2001-12-19T15:00:36+00:00 List-Id: "Mark Lundquist" wrote in message news:cVPT7.3856$xl6.637425@rwcrnsc54... > > If a foundation library included some of those things, and they were (a) > optional, and (b) straightforward to implement on both Unix and Windows, > then I wouldn't lose too much sleep over the other platforms. > Are we talking about putting them into the ARM as an annex? Or simply documenting some kind of pseudo-standard that gets implemented & finds wide acceptance? I'd agree that covering Windows and Unix would account for most things. However, I still think there might be a least-common-denominator problem. It would probably be better for Ada to have its own kind of GUI engine - althought that (like anything else) has its own set of problems. > > It'd be an important step in the right direction, especially for > implementers who appreciate the strengths of Ada but are realistic about the > state of affairs regarding GUIs and IDEs. For them, some more beef in the > "under-the-hood" area might tip the scales in the scenario of > "backend/engine in Ada, UI in Java" (or UI in VC++ if a different team's > doing it and that's what they know), or for web development where the UI is > one of the web scripting languages. > No doubt that adding *any* additional capabilities to Ada makes it more attractive. However, I have not seen many projects that deliberately go out and say "Lets use language X for the GUI and language Y for all the guts..." Sometimes that happens by evolution, but not very often by design. Typically a project is going to have the view that if it has to use language X to do the GUI, it might just as well use language X to do everything - especially since it is common that the GUI is most of the really hard work anyway. So I think if Ada wants to compete in the markets where people develop apps that are GUI based, it needs to have a GUI or it won't likely get chosen. (Oh, yes, certainly. Of course there *will* be exceptions and people can point to projects where this is the case. I'm suggesting that this will be the *general* case.) > Let's not equivocate on the subject under consideration, which is > libraries... while IDEs are important, and also part of the "total package" > along with libraries, we should still observe a separation of concerns > between them. So the aim of a library effort would be to make Ada more > competetive with C++/STL, and also more competetive with Java+JFC modulo the > GUI issue (on that score, Ada and C++ are on a par anyway; that is to say, > you can develop using Claw, Gwindows etc. on Windows and be using the same > GUI as if you were writing in C++, and if you use Gtk on Linux with C++, you > might just as well use GtkAda). > In some ways Ada is better off than C++ when it comes to libraries. One of the things that struck me about the MFC when I first started looking at it was that you could typically divide things into two categories: A) Stuff that was constructed to make up for weaknesses in the Win32api and B) Stuff that was constructed to make up for weaknesses in C++. Most of the stuff in the B category, Ada wouldn't need. Still, having better libraries that were "commonly implemented" (rather than "standard" - since I think that is an overly optimistic goal) would make Ada more attractive. We could probably describe them as belonging to one of three classes: a) Libraries that can be constructed entirely in the Ada language and don't depend on any particular OS or platform or compiler in any significant way. b) Libraries that can have a common interface and a common behavior across implementations, but depend on the back-end being platform specific. (GtkAda is a good example) c) Libraries that are designed to provide access to specific capabilities of a platform or OS. (CLAW is a good example) Things that fit into category A are obviously the easiest things to get constructed and distributed. Concentrating on those things would be good, but I don't think they would in and of themselves be enough to really promote Ada use where it doesn't already exist. Its things in the B or C category that languages like Java offer that makes them attractive for development in domains where Ada doesn't find much acceptance. Personally, I think that Ada could do well by finding its way into the Digital TV Set Top Box because its an area that isn't already "owned" by some other language. Because its relatively new, no one language has any sort of huge toolset that makes it impossible to replace without a billion dollars and ten years of development time. Unfortunately, I don't think Ada will find its way into this domain because most of the guys who know anything about it and are inclined to build software for it are all pretty much die-hard C-heads. But it would be a great opportunity.... 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/