Re: Why don't large companies use Ada?

From: Kursten Schuetz <kschuetz_at_chuckie.raleigh.ibm.com>
Date: 16 Nov 1994 21:55:13 GMT
Message-ID: <3adv41$ap7_at_sernews.raleigh.ibm.com>


I'm looking at the crossposting list for this thread and trying to understand the relevance to database and client-server forums. I can understand and advocates desire to initiate a debate with more application oriented languages such as C and C++, but unless Ada 9X also includes features for transaction control and declarative manipulation of relational structures, what does it have to do with this forum?

A major reason why corporations use the tools they choose is to reduce development time and expense while increasing function. Ada simply isn't designed for many of these information-based needs; relational databases using SQL or a similar declarative language are more optimized for this market. Ada is more appropriate for modular parallel, real-time systems. For corporate information systems, Ada would only be useful in client application code or specialized server-based calculation engines, for which you would still be using integrated vendor products such as OpenServer and OpenClient in Sybase's case. Still, much of the software would be based on the tools' extensions to SQL such as TransactSQL and Oracle's equivalent for procedural constructs for execution on the server. However, Ada could be useful for server code for databases such as DB2 which don't support server based procedural execution but require use of an external 3GL.

I have to disagree that Ada vs. other languages or strong type checking vs. weak type checking automatically makes software more reliable. Based on my own software and that of every software developer I've known in business or academia, choice of language or strong vs. weak type checking has no correlation to reliability. For example, consider string concatenation in C++ vs. Smalltalk (strong vs. weak typing). Memory leaks for such operations occur often in the C++ world. Such problems don't exist in the Smalltalk world. In this example, the real judge of reliability is encapsulation.

I've found that the #1 factor in software reliability is project development  methodology. That's right, how you "manage" software development. (Yech! Now I have to wash my mouth with soap for using the M word!) It's all those little things programmers love such as coding standards, library m...gement, peer code reviews, regression testing, etc. which really make the difference. For real-time systems, even empirical tests are inadequate. Empirical tests won't catch the bug that crashes the plane 1 in 100,000 times. Z-proofs, Petri-nets, etc. are required to prove designs' reliability.

For your argument that C and C++ have been empirically proven to be less reliable, I would like to see your sources. I would expect that the true correlation is not as much the languages themselves, but that Ada programmers in general tend to be more skilled than C programmers in general. This does not mean all cases, so don't anyone flame me for misinterpretion of my words; this means in general. There are definitely more hobbyists and programmers without formal software design backgrounds in the C/C++ community. The Ada community is largely comprised of folks with advanced degrees and much industry experience. Although you might be able to demonstrate that programs written in Ada tend to be more reliable than similar programs written in C/C++, I doubt you could ever isolate the causality to the natures of the respective languages.

Ada was definitely designed for large project development, but that doesn't mean it is automatically ideal for large projects. Ada's project features are that code can be encapsulated into modules for better code management. Many languages and software environments have such features. In fact, the whole concept of object-oriented programming supports this. Also, there are many tools for other languages, such as ENVY for smalltalk, which support  m...gement (there's that word again) of team development.

Kurst

NOT an advocate of cryptic, non-encapsulated, hacker languages of the masses! My views do not represent:

  1. Firesign Theatre
  2. Spotted Owls
  3. IBM PC Company, Research Triangle Park
Received on Wed Nov 16 1994 - 22:55:13 CET

Original text of this message