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=1.1 required=5.0 tests=BAYES_20,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!purdue!gatech!bloom-beacon!mit-eddie!bbn!inmet!ishmael!inmet!authorplaceholder
From: callen@inmet.UUCP
Newsgroups: comp.lang.ada
Subject: Ada in business applications
Message-ID: <124000013@inmet>
Date: 5 Jul 88 15:07:00 GMT
Nf-ID: #N:inmet:124000013:000:3521
Nf-From: inmet.UUCP!callen    Jul  5 11:07:00 1988
List-Id: <comp.lang.ada>


I'm not sure that the following discussion is appropriate for this newgroup;
if not, well, we can move it or drop it. ANYWAY...

There have been a number of postings lately regarding the use of Ada in
commercial business applications. The focus has been primarily upon comparing
Ada with Cobol. Some of the issues are:

- Decimal arithmetic (using a machine's "native" packed decimal representation)
  and the need for computing large monetary amount without rounding

- Size of executables (which I suspect is REALLY size of runtime system),
  speed of compiler, etc.

- Availability of Ada-trained DP-type programmers

- Interfaces to commonly used databases

There is at least one other BIG issue that I don't recall seeing - compatibility
with EXISTING systems. 

The packed decimal issue has two parts. The first is "can we do the same kind of
arithmetic in Ada that we can in Cobol?"  Using Ada fixed point types, I don't
see why not - ASSUMING that the compiler will support large enough ranges. If
the underlying rep is 32 bits max, then we have a problem. The OTHER part is
"can my new Ada program read my old payroll tapes?"  THAT'S where you need the
packed decimal, and you can't get around it. If this compatibility requirement
is a biggie, then you also want the packed arithmetic to be EFFICIENT; doing
things "the Ada way" by defining a packed decimal package and then coding
all of the operations by hand just won't fly. Maybe defining an interface pack-
age and coding the routines in assembler would do. The RIGHT solution is for
the compiler to support packed decimal as a native data type.

The RTS size, compiler performance, etc. issue will go away with time, just as
it did for Cobol (I still remember 45 minute compilations of a 2000 line Cobol
program on a Honeywell H2050.) Likewise for the Ada-trained programmer problem
and the database interface problem. (I realize that this doesn't help anyone
right NOW, but...)

Backward compatibilty is likely to be a BITCH. One of the first things you
are going to have to do is read files written by Cobol programs, and probably
also produce files to be read by Cobol programs. Since Ada compilers are
free to order record components as they see fit, you will need to use record
rep specs in a big way, and some Cobol record structures are NOT going to be
easy to handle in Ada. 

I guess I think we are asking the wrong sorts of questions, though. Ada is
a GREAT general-purpose programming language. But data processing is a SPECIFIC
application realm, and I feel that there are FAR better tools IN THAT REALM.

For instance, much of what business computing is all about is reading stuff
off a tape, doing a little processing on it (computing totals, producing
page breaks when some field changes, etc.) and then printing it. For that
job that are MANY "file management programs" (my term) that are decendants
of RPG (even if they look nothing like it) that make this job incredibly
simple - 10 lines of input to produce EXACTLY what you want. Why do that in
Ada? Smart shops don't do that in Cobol, either.

Another big chunk of business computing is online, transaction-driven systems,
such as ATMs, account inquiry/update programs, etc. For these, Ada MIGHT be
better than Cobol, presuming that the right data types are available (the 
packed decimal issue again). But I'm not yet convinced. 

I don't hate Ada. I LOVE it. But I'd hate to write a payroll system in it.

-- Jerry Callen
   callen@inmet.inmet.com
   ...{ima,harvard}!inmet!callen