Ada in Client/Server (was: Borland Ada)

[Howard.Gilbert@yale.edu]

In <ichbiah.239.2F4C00CF@jdi.tiac.net>, 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