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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6e16e39504a85f4e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-02-28 07:17:11 PST Path: nntp.gmd.de!stern.fokus.gmd.de!ceres.fokus.gmd.de!zib-berlin.de!fu-berlin.de!zrz.TU-Berlin.DE!netmbx.de!unlisys!news.maz.net!news.ppp.de!xlink.net!howland.reston.ans.net!gatech!udel!news.mathworks.com!zombie.ncsc.mil!admii!cmcl2!yale.edu!news.ycc.yale.edu!news From: Howard.Gilbert@yale.edu Newsgroups: comp.lang.ada Subject: Ada in Client/Server (was: Borland Ada) Date: 28 Feb 1995 15:17:11 GMT Organization: Yale University Message-ID: <3ivepn$ljm@news.ycc.yale.edu> References: <60.18011.4393.0N1D0B41@canrem.com> <3ianqv$ghb@Starbase.NeoSoft.COM> Reply-To: Howard.Gilbert@yale.edu NNTP-Posting-Host: gilbert.ycc.yale.edu X-Newsreader: IBM NewsReader/2 v1.09 Date: 1995-02-28T15:17:11+00:00 List-Id: In , ichbiah@jdi.tiac.net (Jean D. Ichbiah) writes: > >Ada has a future only if a bridge to faster development tools and >frameworks (such as OWL) can be established. Without this kind >of bridge, Ada will not be cost-effective for developing Windows >applications. If Ada ends up not being a cost-effective way to >develop, how will anyone be able to continue supporting Ada? > Although many people talk about Client/Server, they usually only consider the hardware. IBM's SAA was the worst example, an entire architecture based on the assumption that people would program the same languages and interfaces on PC's and mainframes. One of the advantages of C/S is that you can choose technologies at each level in the hierarchy. Ada may be a wonderful language, but it is unlikely that anyone will invest the amount of effort needed to build the surrounding infrastructure of development environment, GUI interface, database interface, case tools, and all the rest. Even with the investment, it is simply not true that Ada will ever compete head-on with Visual Basic. So maybe the Client isn't the best place to concentrate effort ("Programming in the Small"). On the other hand, Clients need a Server. Server code can be complex logic, multi-tasking, mission-critical, performance sensitive, and all the other stuff for which Ada was designed. The Server doesn't generally need a GUI binding. What it does need, however, is access to the Interface. Support for the DCE environment and remote procedure calls is probably the highest priority. Then, in some order, one needs Sockets (general TCP/IP), CPIC (IBM mainframe and AS/400 communication and transaction processing), maybe named pipes. In the older PC operating systems, it might have been necessary to run everything in one module in one language. However, with OS/2 and WIN32 an application can be componsed of separate processes linked by Interprocess Communication. Leave the front-end to lightweight modules written using high-productivity, low-reliability languages. Write the backend in languages that encourage reliability. Old Ada discouraged communication between languages. The DOD 100%-Ada mandate seemed to justify this design, but it simply left the decision as "all or nothing" and that really meant 0%. Ada 95 is much more flexible in its approach. I am not suggesting that Ada should never get an interface to building "pulldown combo boxes," but I would suggest that the effort be placed first in pipes, sockets, RPC, SOM, and CORBA. Play to the language strengths. In particular, the current language of choice appears to be C, but that language was specified for the Unix environment and has serious shortcomings running multithreaded. Putting C++ on top of C doesn't fix the original structural deficiencies. Since Server code is almost necessarily multithreaded, a language orignally designed to synchronize concurrent access to storage by multiple tasks has a clear advantage. Ada has no special advantage when deciding if the Window title should be in Times Roman or Perpetua Bold. --------------- Howard Gilbert -- Chief Mechanic at PC Lube and Tune Technical training on PC's, networks, and communications. Point Netscape or WebExplorer at http://pclt.cis.yale.edu/pclt/default.htm