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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public From: demer@hc17031.hcsd.ca (David Emery) Subject: Re: Any research putting c above ada? Date: 1997/04/18 Message-ID: #1/1 X-Deja-AN: 235894126 Sender: demer@hc17031.hcsd.ca References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu> Organization: HCSD Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-04-18T00:00:00+00:00 List-Id: clines@airmail.net (Kevin Cline) wrote >1. No reasonably usable bindings to key external components: operating >systems, windowing systems, databases. Geez, I never had any problem "rolling my own" Ada bindings when needed. And I've been doing Unix system-level programming since 1984... >2. Expensive compilers of rather poor quality. True... This is where the DoD "captive market" hurt. Many of us argued in 1985 that the best thing the DoD could have done at that point was to produce/release a free Ada compiler, with full source, a la GNAT. (The Intermetrics AIE was one candidate.) The availability of GNAT has really helped Ada. It's also helped GCC/other GNU translator developers, by adding features and increasing the quality of the GCC interface and back-end. >3. The language moved much too slowly while the software market completely >changed from mainframes and minicomputers with dumb terminals to client/server >systems. Ada83 lacked key features needed to develop client/server systems. See #1. I did my first "client-server" system in Ada83 in 1987, using Sun ONC RPC. What key features does Ada83 lack that any other -language- provides for Client-Server? Fast/efficient client-server support needs a. good client-server infrastructure ("middleware") b. bindings to same c. tool support My observation on Ada bindings has been that a. Ada83 went way farther than any previous languages in supporting mixed-language programming. (Try connecting software written by 2 different C compilers...) b. There were some tricks to writing interfaces to C. Most of these tricks worked on most compilers, although they were not guaranteed by the language. c. The time spent producing a good binding to C was recovered by substantially reduced debugging time in the application. Thus, if the binding were to be called many times, we spent more time getting it "better" (i.e. "thicker"). If there was only one or two points of call, then we'd just cobble up "pragma interface (C);" Ada95 codifies many of these tricks, and fixes a couple of places where compiler support was necessary. I don't know of any other language that approaches Ada83's support for mixed-language programming, including control over data layouts, etc. Ada95 is clearly ahead of the pack, but of course this has been out of necessity, because most commercial products come with a C interface. The big problem in my experience has been a language-independent problem, and that's the quality of the interface. Some vendors provide high quality, well-engineered interfaces, and others provide terribly hacked-together interfaces. The former make it easy to use the product from -any langauge-, while bad interfaces are bad interfaces, regardless of the language of implementation. It remains to be seen if CORBA IDL produces a "paradigm shift" in interface definitions. I've seen well designed IDL, and I've seen IDL that looks like bad C. dave -- Note: if email to me bounces, use 'emery@grebyn.com'