TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Gilbert Prine <[log in to unmask]>
Sat, 10 Oct 1998 02:31:04 -0400
text/plain; charset="us-ascii"
Gilbert Prine <[log in to unmask]>
text/plain (52 lines)
I would like to try to answer Neil's only question.

>why people aren't using it.  It is just a lack
>of training, lack of decent advertising, cost of manpower involved?

Probably the main reasons that people aren't using Ada have less to do with
the language itself than its history.  Its initial version, Ada 83, assumed
that the Ada run time system was in complete control of the computer and did
not have to interface with any other language or operating system.  This was
because the original requirements for "DoD1", which became Ada, were created
for a stand-alone embedded system.  In the mid to late 80s it became clear
to Ada compiler vendors that this wouldn't work in the real world and many
different interface solutions appeared, some were awkward and all were
non-standard since there was no requirement for any interface.

At the same time the Department of Defense had several levels of response to
a "mandate" that Ada be used as a standard programming language for mission
critical systems.  Oversimplifying the problem, many DoD contracting
officers did not understand what Ada could do for them and/or exactly what
the mandate meant.  Computer contractors found out they could avoid the
whole issue by bypassing the mandate and using whatever language they
wanted.  For many of us who realized the software engineering benefits of
Ada 83, it looked like a political "food fight" both inside and outside of
the DoD (it even reached the level of language in Congressional laws) that
was independent of the technical issues.  Also, the first Ada compilers were
very expensive and were not very good technically.  This created an early
impression among many that Ada was no good and the only reason to use it was
because it was mandated.  This impression is still held and expressed by old
timers who were on the "wrong" side of the food fight.  In my opinion, the
DoD inadvertently created a techno-economic model that has been negative for

Ada 95 solved the technical problems with excellent interface additions as
well as true object constructs and other improvements, and it is the only
programming language that I personally would consider using.  There are also
a number of very good Ada 95 compilers/development systems.  However, by the
time Ada 95 became competitive C, C++, Perl, Visual..., Html, etc. all had a
head start and greater popularity with programmers more interested in
toolsets that allow easy program creation than in systems that are
engineered with high reliability and are highly reusable.  Ada 95 may well
remain a niche language for mission critical systems such as transportation
and medical applications that *must* work right - the first time.

Let me get off that soap box and mention Ada's under-used direct_io.
Combined with parts of the Ada tasking model, and with careful system design
it can be an effective custom database engine for any table with less than 4
billion rows.  I run a 10GB data mart that uses Ada direct_io very flexibly
and cost effectively both as a multi-dimensional datacube and as a data
mining engine.

Gil Prine