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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b19fa62fdce575f9 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-11-20 00:11:33 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!pipex!uunet!ois!beckwb From: beckwb@ois.com (R. William Beckwith) Subject: Re: Why don't large companies use Ada? Message-ID: Organization: Objective Interface Systems, Inc. X-Newsreader: TIN version 1.2 PL2 References: <3a6oc5$dkh@nntp1.u.washington.edu> <3aj9a3$4am@s-cwis.unomaha.edu> Date: Sun, 20 Nov 1994 07:09:20 GMT Date: 1994-11-20T07:09:20+00:00 List-Id: Jean D. Ichbiah (ichbiah@jdi.tiac.net) wrote: : On a more positive side, the object-oriented features of 9X offer some : hope: see the article by Tom Quiggle - Re: SGI inheriting C++ classes - : later in this conference. : This may be the best chance for Ada to survive: One one hand, there : is no way the Ada vendors could do the kind of investments that has been : done in class frameworks developed around C++, Borland Pascal, or the : forthcoming Delphi. My guess is that we are talking of several hundred of : man-years and it is clearly out of question to duplicate it. (I do share : your opinion about current Windows bindings and the fact that Ada : development for Windows is consequently overly expensive.) : But this approach of inheriting these frameworks at moderate cost, : offers a chance to put Ada back into the mainstream applications. We at OIS have debated on whether to interface to existing C++ libraries or rewrite them several times. Our windows version of Screen Machine was built above a C++ class library. This caused considerable grief in terms of interfacing complexity (we hand-built the interface code to do what the GNAT C++ interface does), memory management (earlier versions of the C++ libraries leaked memory), and design clarity. More recently we decided to base our future Ada GUI products on the X11R6/Fresco system. Thus, we faced the decision to reuse or rewrite again. This time we chose the path of rewriting the C++ in Ada 9X. We are _very_ happy with our decision. Since Fresco is based on CORBA the Fresco interfaces are defined in IDL. Via a nice clean mapping from IDL to Ada 9X, we could build cleaner, simpler Ada 9X implementations of the Fresco graphical classes. C++ has many arbitrary complexities that would have precluded a straightforward Ada interface. It just doesn't seem right to make an Ada programmer pass a null object pointer as an argument to a program that really should have an `out' parameter (one small example). Rewriting the C++ code in Ada 9X has allowed us to remove a considerable amount of unnecessary C++ code and complexity. We felt that the GUI toolkit is so pervasive in an application that the toolkit needs an especially clean API. We think the new Fresco Ada 9X interface achieves this goal because of the rewrite. It would be nice to see other domains dispense with bindings and build directly in Ada 9X. The code can sometimes be smaller than the binding code would be. (BTW, if C++ programmers want to reuse Ada 9X Fresco widgets then they just generate the C++ client interfaces with a C++ IDL compiler.) The Smalltalk community has chosen to write their graphics toolkit in Smalltalk. They don't use Motif widgets. I think the results are a very tight integration between the user interface graphics and the native language. They have defined their own framework. There are certainly many domains where the cost of rewriting can't be justified to achieve a superior API. It's nice to know that the C++ code can be reused. However, if you are going to reuse the code frequently I suggest applying the power of Ada 9X directly to the problem via a rewrite. Otherwise, the C++ code you reuse may be your biggest detriment. ... Bill