Re: A farewell to Ada

[schwartz@dinl.uucp (Michael Schwartz)]

OK.  You win. I have to put in my 2 cents' worth.  It's hard, because I
agree with many things that everybody has said.

Ada has been getting a bum rap.  Ada was not designed by committee, it
was designed by competition.  C, on the other hand, has been judged by
its applications.

Ada had no substantial applications to benchmark its design against.
The software engineering requirements imposed on Ada were for
programming in the large.  Precisely what Ada has been shown to be good
at.  Not surprisingly, Ada has not been found perfect for every
application area.  Where it has failed, Ada-9X proposals have been
submitted to change it.

C was developed for systems programming.  The worth of a compiler was
judged by the ability to build a good, modular, maintainable operating
system.  Where C failed, the language was changed.  And changed.  And
changed.

It has surprised no one that C is more responsive to change requests
than Ada.  Nor is it surprising that inexperienced software engineers
write better code in Ada than in C.  It has not escaped anyone's
attention that there are more inexperienced software engineers than
experienced software engineers.

Sorry for belaboring the obvious, but let's start somewhere.  Now let's
talk about Ada and Unix.  

Areas where Ada and Unix have problems:  a) System-dependent features
accessed from Ada b) Scheduler conflicts--Ada tasks vs Unix tasks c)
Ada image sizes and startup times

Of these areas, (c) is the most readily addressed.  I have heard a
number of Ada 9X proposals amounting to a mechanism to freeze the Ada
image after elaboration, but before execution.  So much for startup
times.  I have also heard several vendors tout smarter link-editors
which will help resolve image size problems.  I also hold hope for
shared library implementations; the Ada runtime can be shared among all
processes needing it.

Area (a) is one that requires Ada vendor support.  It is difficult to
think of a non-trivial software system without some system-dependent
feature.  After all, we buy different hardware precisely because of
these features.  In my mind, a major difference between a good Ada
compiler and a marginal one can be found in the support for operating
system signals, pragma interfaces, and representation specifications.
It is no anathema to me to have an Ada system contain bodies which are
Pragma Interface (C,...) EVEN IF I DON'T HAVE TO.  Maintenance costs
must be kept foremost.  Reducing maintenance costs is, after all, one
of the major considerations in developing Ada.  Let's not spoil this by
insisting that every Unix guru learn Ada.

Scheduler conflicts (b) remain a problem because Unix processes are not
the same as Ada tasks.  Several have pointed out that Ada tasks are
'lightweight'; they mean that Ada tasks are represented by different
execution threads (instruction pointers and stack frames) but the same
data space.  At least one Unix vendor has implemented a lightweight
process type in the Unix kernel.  It is possible that a good solution
will be to build an Ada compiler which maps its tasks to lightweight
Unix processes, letting the Ada scheduler be either eliminated or
vastly reduced.

In the absence of this solution, a multi-tasking Ada program must build
a monitor to mediate all operating system calls which may 'use up' its
most vital resource -- the Unix operating system process.  The
efficiency with which this may be done is directly related to both the
Ada compilation system's (ACS) ability to interface with Unix (see
(a)), and the 'goodness' of the Unix in question.

Since 'signals' are to Unix more or less what 'rendezvous' are to Ada,
the more events which can be propogated to the Ada monitor from Unix
via signals, the more efficient the implementation.  Broad support for
SIGIO seems to particularly help.

With current compiler technology, one published result we have obtained
is multi-tasking access through sockets within 20% of the performance
of a C program using standard fork() and exec() calls.  Both
applications were able to exchange over 5000 tcp/ip messages per
second with a cheap 68020 box.  Turning off the time-sliced tasking in
the Ada program helped significantly.

One other result is that using our Ada abstraction, new employees were
able to contribute to our project within one to two days, even with no
prior Unix experience.  Of course, a C abstraction is possible--but why
doesn't anyone use one?

A 'today' note: Dennis Ritchie spoke to the FRUUG (Front Range Unix
Users Group) last night about 9th Edition IPC.  He has developed a
different IPC abstraction for his research.  In syntax, it is similar
to our Ada (and C) abstractions.  Of course, it has kernel support :-).

There.  I feel better now ('thar she blows!)

Michael
-----------------------
schwartz@pogo.den.mmc.com  "Expect everything ... 
mschwartz@mmc.com                   and the unexpected never happens." 
ncar!dinl!schwartz                               --the phantom tollbooth

DISCLAIMER:  The opinions expressesed are not necessarily those of my 
	     employer or myself.

-- 
-----------------------
schwartz@pogo.den.mmc.com "Expect everything ... 
mschwartz@mmc.com                   and the unexpected never happens." 
ncar!dinl!schwartz                               --the phantom tollbooth

DISCLAIMER:  The opinions expressesed are not necessarily those of my 
	     employer or myself.