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-22 11:51:57 PST Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!swiss.ans.net!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody From: dewar@cs.nyu.edu (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Why don't large companies use Ada? Date: 22 Nov 1994 08:56:48 -0500 Organization: Courant Institute of Mathematical Sciences Message-ID: <3astb0$bji@gnat.cs.nyu.edu> References: <3a6oc5$dkh@nntp1.u.washington.edu> <3aj9a3$4am@s-cwis.unomaha.edu> NNTP-Posting-Host: gnat.cs.nyu.edu Date: 1994-11-22T08:56:48-05:00 List-Id: First, I don't think that there is as much disagreement between Bill and Jean as appears on the surface. Bill is not saying that everything should be reengineered, and Jean is not saying that nothing should be reengineered. I do think Bill goes much too far when he says that reuse is for projects not products. Let's take the SGI Inventor example. If SGI is to succeed in promoting Ada 9X, they have to provide usable interfaces to their primary capital advantage, which is a huge library of impressive graphics stuff. If the Ada enthusiasts inside SGI told management that this entails a lot of reengineering, it is simply a nail in Ada's coffin in terms of being accepted as a feasible alternative. SGI needs to be able to provide productized versions of these interfaces, which are heavily object based, and require the capbility of extending existing classes, with absolutely minimal effort. Reuse is *the* key to seeing Ada 9X as a feasible technology in this environment. I am not saying that everything can or should be done this way, but the important point is that in the past we have always had the necessary tools for doing the kind of reengineering that Bill is talking about, and there are indeed examples of positive results from this (one reimplementation of Motif for Ada turned out to be much more reliable and efficient than the original), but missing was a reasonable technology for reuse. What is exciting to me is that the combination of New features in Ada 9X promoting easier interfacing New features in Ada 9X to interface to (notably the OO stuff) Technologies for more direct binding to C++ (as implemented in GNAT, and hopefully similiar or superior approaches will appear in other Ada 9X compilers) AUtomatic binding generating tools of the kind demonstrated by SGI seem to point in the direction of a practical reuse technology for Ada 9X which was sorely lacking in the Ada 83 case. This does not mean that I think Bill is going in the wrong direction in his efforts, on the contrary, I think he is on track to providing some very powerful, and very comfortable-to-use interfacing to some important technology. What it *does* mean is that we don't have to depend on such re-engineering efforts for cases where at least at first it will be impractical to follow anything other than a reuse path. Now if Ada 9X becomes so successful that Microsoft, Borland, ... do all their programming in Ada 9X, then presumably all these wonderful interfaces will indeed be reengineered in Ada 9X, but till then ... :-) :-)