Re: Why don't large companies use Ada?

An important distinction in this debate is client based vs. server based software.

In article <CznDz0.A1G_at_ois.com>, beckwb_at_ois.com (R. William Beckwith) writes:
|> Kursten Schuetz (kschuetz_at_vnet.ibm.com) wrote:
|> : So, since Ada does not provide any advantages for DBMS systems, its
|> : use in a business environment is limited to front-end development
|> : and possibly some specialized calculation engines (from my previous
|> : post).
|>
|> Ada does have several nice advantages to almost all 4GL's and most
|> 3GL's. One critical feature to responsive applications is
|> client side multi-threading. Use async I/O with GUI callbacks
|> is really messy. Ada's built in multi-threading allows for
|> simple, clean programs that don't make the user interface wait
|> for query results. Programmers can easily create applications that
|> let users queue up multiple queries and transactions.

Although Ada and other 3GLs offer advantages over client-side 4GLs, the server end is still better implemented using the DBMS 4GL, especially for complex procedural transactions. The alternative: developing server code in a 3GL with static-SQL and re-implementing the network communication layer is incredibly inefficient.

For clients, other 3GLs can also handle multi-threading and provide a standard OO syntax. Even non-preemptive environments such as VisualWorks offer simple mechanisms for multi-threaded type applications. However, for many companys' OLTP systems, multi-threading is not important, because applications require frequent access to centralized information and response is fast. This is one reason for the popularity of client 4GLs.

|> With good extensible 3GL's toolkits can offer elegant class
|> heirarchies for setting up transactions, manipulating tables,
|> running stored procedures, etc. This allows for the graceful
|> mixing of Transact-SQL with the 3GL. You end up with a 3GL
|> based toolkit that has the power and productivity of a 4GL
|> but in a more robust language environment. Take a look at the
|> 2.0 version of Sybase's Ada Workbench if you get a chance.

The question I have here is whether or not the OO style data manipulation is executed in a client/server style. For example, let's compare the hierarchical compositions of several objects for similarities in a RDBMS. This model has no constraints on depth or symmetry of the hierarchies. A true client/server process would accept the parameters and produce the final answer without any interaction with the client. A system which limits server execution to standard SQL operations and implements the hierarchical flexibility in the client is far less efficient. Passing intermediate steps between server and client will kill your performance, especially across a WAN or highly utilized LAN. The 100% server-based 4GL offers a much better performance curve.

|> : To address the question which started this whole debate: What does
|> : Ada give me that exceed what I've already got? *I* don't know.
|>
|> 1. multi-threading
|> 2. clean, standards based object oriented 3GL language
|> 3. with Ada Workbench: nice class heirarchy for data
|> manipulation

Again, what does Ada give me that exceeds what I've already got? I've got this now with other 3GLs. For businesses to switch to Ada, there must be reasons which outweigh the benifits of environments currently in use. Most companies use 4GLs because they don't need the sophistication of a full 3GL. Companies which require the flexibility of a 3GL prefer to keep their software syntax the same, even if they're trying to make the conceptual leap from procedural to object oriented software. This is why languages such as C++ are so popular and products such as object oriented COBOL even exist.

For businesses which are investigating "going client/server," and do not have substantial investments in other technology, Ada offers a good solution for client software.

Kursten Schuetz

The wonderful thing about standards is that there are so many to choose from! My views do not represent the IBM PC Company, Research Triangle Park. Received on Wed Nov 23 1994 - 01:49:36 CET