From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 15 Dec 92 19:45:20 GMT
From: elroy.jpl.nasa.gov!grian!puffin!pete@uunet.uu.net  (Pete Carah)
Subject: Re: Open Systems closed to Ada?
Message-ID: <BzBG7L.G3A@puffin.uucp>
List-Id: <comp.lang.ada>

In article <1992Dec13.151515.27646@sei.cmu.edu> ae@sei.cmu.edu (Arthur Evans) w
rites (quotes...):
>    QRS [the pseudonym for the defense contractor, which is not
>    identified] is convinced.  It has now decided to use Ada extensively
>    because it believes the use of Ada will provide the company with a
>    competitive edge in the market place.
Or when the compiler isn't better for particular cases (e.g. device drivers
and, say, specialized display drivers for which you want to unroll large
loops, etc), one can prototype in ada and hand-convert to assembly when
the program is debugged.  Of course, assembly optimizations and the
related ada source optimizations may not exactly correspond.  However,
this may make the assembly development both faster and more reliable.
I have done this several times in 286-based systems using the Meridian
compiler (whose optimizer wouldn't handle programs as big as ours at the
time, and which wasn't as good at PARTICULAR optimizations specific to
the task as we were).  Ada's package isolation makes this easy to
manage.

Ada is certainly not a bad language; it wasn't nearly as well supported
as C for its first 5 or more years, but that is finally getting better.

I have objections to the mandate being used to force, say, 20-30 (or even
several hundred) line snobol (or awk, for example; there are related
problems in non-text situations too) programs to be developed in ada
where the result (because of lack of associative array packages, for
an example from awk) would require thousands of lines of ada to be
written.  The symbol table packages in the repository are in general
not very portable - we DID try to use several of them (in other
situations) and ran into problems with compile-time symbol-table size,
and generated-code segment size (remember this was on a 286).

If the program volume in the repository ever gets up to even
comp.sources.unix (which has been a very low-volume group lately) it
may start to be useful.  Note too that the only program from the
unix sources groups which I've had problems with on a 286 was pathalias
(for the hash table for system names).  (compress has similar problems
but since the hash table is fixed size, someone solved that problem
long ago.  The result runs even in MSDOS real-mode.)

-- Pete