Re: Why don't large companies use Ada?
Date: Tue, 22 Nov 1994 02:37:48 GMT
Message-ID: <CznDz0.A1G_at_ois.com>
Kursten Schuetz (kschuetz_at_vnet.ibm.com) wrote:
: The argument that a general-purpose language is more mature when it
: comes to data abstraction is false. The issue is declarative vs.
: procedural semantics of your DML. For relational structures, I've
: written the same programs in Transact-SQL, C, and Smalltalk. Not
: even Smalltalk approaches the power and elegance of SQL with Sybase's
: extensions for accessing and manipulating relational data structures.
: The reason is that the declarative nature of DMLs such as SQL signifi-
: cantly reduces the demands for the programmer to understand, design,
: and develop the best access plan and data integrity control for his
: processes.
Using a O-O 3GL (like Ada) doesn't mean you have to define you data abstractions in the language. Doing so would be similar to putting record definitions in your COBOL programs. The age old argument is that putting this information into the client makes the change management cumbersome. Note that with the OODBMS's you do define the data abstraction in the 3GL.
: My own project is another argument that 4GL data abstraction is not
: inherently inferior to 3GL abstraction. I'm developing an IS for
: which portions of the data model are object oriented. All data
: manipulation is performed in Sybase using Transact-SQL. This system
: may not have polymorphism, but it does have inheritance, abstraction,
: and encapsulation... 3 of the 4 criteria of an OO paradigm. It works
: quite well, too, outperforming the C program it replaces by orders
: of magnitude for large data sets and providing multi-user access.
: Implementing our solution with Ada or any other 3GL would have been
: a monumental waste of time and money and never could have been
: completed with our limited resources.
Many traditional 3GL applications don't take advantage of an SQL Server's capabilities. Programmers write nested loops instead of using joins, etc. Obviously the server can perform joins and selections much faster than the clients.
: 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.
Ada's other advantages for information systems have to do with general language advantages and I won't get into that discussion here.
: For specialized calculation engines, companies would still
: use tools such as OpenClient and OpenServer to interface them to
: the DBMS. I haven't investigated any user interface development
: tools which generate Ada code or use Ada in any fashion. Do any exist?
Yes. Several.
: Even if they do, the front-end market is dominated by 4GL tools such
: as PowerBuilder and VisualBasic. Even for 3GL front-end development,
: the market is dominated by products based on Smalltalk, C++, and
: Objective-C, such as VisualWorks and NeXTSTEP.
Again, check out Sybase's Ada Workbench 2.0.
: 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.
- multi-threading
- clean, standards based object oriented 3GL language
- with Ada Workbench: nice class heirarchy for data manipulation
: All of my issues are covered, and I don't know of a single product
: from the Ada community which could improve what I am presently using
: for my corporate information system.
You should take a better look. Ever wonder why Reuters writes a good number of their Sybase applications in Ada?
: Kursten Schuetz
... Bill Received on Tue Nov 22 1994 - 03:37:48 CET