Hello.

I am a long time C programmer (10 years plus), having a look
at Ada for the first time. From my (inadequate) testing, it seems
that performance of average Ada code is on par with average
C code, and there's a clear advantage in runtime safety. The
GNU ada compiler makes pretty sure that there are very few
platforms without easy access to Ada, so portability should be
on at least an equal footing too.

My question is: how come Ada isn't more popular?

This isn't intended to start a flame war, I'm genuinely interested.

thanks,
MC

news:1169531612.200010.153120@38g2000cwa.googlegroups.com...
Ada suffered, in its early days, from a convergence of several
things.  One is that the designers of the language did not anticipate
the impact of the personal computer and the democratization of
computing.   There were other factors, as well.

1)  The DoD mandated Ada before there were any good compilers
     or development environments in place.   That began a routine
     practice of rubber-stamping waivers to use other languages.

2) The compiler publishers, having a captive audience, inflated the
     price of compilers and tools, making Ada unattractive for anyone
     in the non-DoD world.  For example, Alsys sold a compiler for
     the personal computer at $4000 per copy thereby putting out
     of the range of most companies and every hobbyist.

     Turbo Pascal and other alternatives were already in place and
     much cheaper than Ada.   A few brave souls tried to compete
     with products such as RR Software's Janus Ada and Meridian's
     AdaVantage, but the full environment (e.g., integrated editors,
     debuggers, etc.) were not in place they were for Turbo Pascal.

3)  Inept DoD management of the Ada initiative.  Sometimes it seemed
     that the DoD was trying to make Ada a bad choice for businesses.
     The public line was that they wanted commercial users, but the
     practices often put barriers in the way.

4)  Other languages were cheaper to acquire, cheaper to use, and had
     no copyight associated with them.   The copyright was eventually
     removed, but late.

5) The earliest compilers were not uniformly good.  I recall the mainframe
    compiler from Telesoft was, when compared to other language choices,
    simply terrible.   It was slow, had an awkward development environment,
    and did not support the central features of the mainframe very well.

    Many of those early compilers were "checkbox" compilers.   On the form
    where one had to check-off "Validated Ada Compiler" the fact that a
validated
    compiler was available was considered enough.   One compiler I recall quite
    vividly was for the Tandem.   Although the compiler was validated, that same
    compiler was not integrated into the rest of the system tools, and barely
    supported by the operating system.   The word in the Tandem management
    was that no one was expected to take Ada seriously, but the checkbox had
    to be supported.   This was quite widespread in the industry.

6) Really good compilers began to appear around 1989.   By then Ada's reputation
    for being slow, cumbersome, and hard to use had already been firmly set.

7) Instruction in the language was bad.   I recall a U.S. Navy Admiral
complaining
    about how hard it was to teach anyone Ada.   He described the efforts he put
    in place to make this happen.    I told him he had hired people to do the
teaching
    who were incompetent.   That was true, but they had PhD's and he thought
that
    should have ensured success.   The fact was that those teachers had not yet
come
    to a full understanding of the Ada and their own confusion was more a source
of
    obfuscation than enlightenment for the students.

8) Grabbing defeat from the jaws of victory.   In the mid-90's, when Ada became
    a powerful alternative to other languages, when tools were in place, the
language
    modernized, and the availability of low-cost (or free) compilers could have
made
    it attractive, the DoD lost its nerve and gave the impression that Ada was
no longer
    part of the DoD language requirement.  A lot of people misinterpreted this
and thought
    the DoD had decided to abandon Ada entirely.

9) Traitors.   Some people who were previously charged with promoting Ada, in
     particular certain former AJPO officials, once having left government,
exploited
     their former role and joined the forces against Ada.   They were able to
use their
     title as former ... to gain credibility and lobby against the use of Ada in
exactly
     the places where it was appropriate to lobby for it.

Ada is not now, nor has it ever been, the perfect language.  There is no perfect
language.  However, anyone who understands Ada and has a good understanding
of the competing technologies realizes that Ada continues to be the most
appropriate
choice when the requirement is for a language that will improve the probability
of
an error-free software product at a reasonable cost.  The alternatives, mostly C
and C++ are generally less dependable.  In fact, I often wonder why anyone would
pick a language that is inherently error-prone (e.g., C++) and expect a result
that
is error-free.

If one does an objective comparison of Ada to its alternatives, in the design
and
constuction of dependable software, Ada will come in with high marks -- higher
than most alternatives.   If one is looking for a language that is well-suited
to
supporting a long-lived software system, Ada is certainly better than most of
the alternatives.

More could be said in favor of Ada.   I will leave that more to others.

Richard Riehle

Ah, politics and dramatics! It's had quite a history then - always
a killer.

Thanks for the impromptu documentary.
MC

This has been asked several times, and I think you'll get many opinions.
There are historical reasons, but by now, they are no longer relevant.

In effect, there is no real reason why she isn't more popular - I
personally cannot understand this. Most of the arguments you hear
against Ada are in fact made up - people just don't want to use her,
they're happy with whatever they're using.

Mind you, I do not argue that there are strong reasons why some project
does not use Ada - we're talking popularity here.

Because most people don't have the same attitude towards language
evaluation that you do.

Most that I've actually asked have the attitude "C was what I learned
in college, and it's good enough for me".

Or, in managers, "everyone else is using C, so it must be the best
language". When I point out that far more programs are written in
Visual Basic, or Excel, they look very puzzled :).

Welcome to enlightenment :).

--
-- Stephe

Grein, Christoph (Fa. ESG) wrote:

Popularity is the key thing surely - the chicken and egg. As a software
manager in a commercial business, I employ C programmers because there
are so few Ada programmers around in the UK. There are so few Ada
programmers in the UK because I employ C programmers! How do you break
that chain?

There are many examples in marketing history of inferior products
becoming the more widespread, e.g. Betamax v VHS video recorders, MSDOS
v Concurrent CPM-86. I guess this is just another one of them.

Others have given longer scoped responses, and I will concentrate on the
hobbyist POV (I have felt an Ada hobbyist for a long time now): there is a
catch-22 problem with Ada and it is the lack of libraries. This is a
relative problem, consider these points.

1) The standard library is really standard, so this is an advantage if it
does all you need. Also some features (e.g. fixed point, bound checking,
tasking!) are in the language so you don't need extra wrappers around the
basic language or OS.

2) There's no good, easy, almost automatic C binding generator, although the
language has well defined mechanisms for C interfacing. Yes, there was some
generator. No, it is not trivial at present to get it running in my
experience. There's some effort to have Ada integrated into SWIG; this is
promising and IMHO an important selling point to newcomers.

3) There are bindings for quite some important things: Gtk+, Xml parser,
Unicode, CORBA, databases...

Summarizing, the Ada programmer feels a bit pariah when he sees his fellow
C/C++/java friends trying the latest and greatest version of some library.
Either it is unavailable for Ada, or is not up to date, or has to invest
some time in creating or tweaking a binding.

This is something that, as I said, may be important or not at some point,
depending on what you need to do. Also going against the majority of
colleagues is a burden. In my lab almost all development is done in matlab,
C or C++, and these are not all CS people but from other engineering
branches too. It's a shock when you have to use other's code and start to
see random pointers in function declarations, arcane syntax for complex
datatypes (because typedef seems a forbidden word) and so on. In my case,
Ada isn't event a obscure language: it is taught in my university and has
good backing among several high-profile teachers. Even so, I feel very
alone... :)

[about bindings - and their lack of]

For libraries that are no more developped, like some compression or
image formats, an alternative is to get an Ada translation and not
needing a binding anymore (a problem with a binding is that you have to
provide it and keep it up-to date for each compiler/OS/CPU
architecture, and accept that the quality of the bound library
fluctuates with the time...).
If you are lucky, there is a Pascal translation around and you can go
further with P2Ada, it is much easier than translating from C which is
very different.
It is also a good occasion to seriously debug these libraries.
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Quality is not free - short term.
Quality costs are traditionally split in:
- preventive costs
- inspection costs
- error costs, which are split in:
  - external error costs
  - internal error costs

Investing in Ada people belongs to the preventive quality
costs which hopefully are paid back at a later stage.

So, breaking the chain is a long term process which in the very
beginning does not produce much more than costs.
But in the long term ...  

I don't know what "this" refers to. :(

--
Anders

In article <L2ith.12633$ji1.1...@newssvr12.news.prodigy.net>,

Richard Riehle wrote eloquently on this subject. I'll add one more point.

Ada came out at a time when the government in general and the defense
Department in particular were widely perceived as evil. Since Ada was
intended to be used to write programs that would kill people, some
perceived it as inherently evil. Many folks, myself included, made the
argument that wrenches are used to build weapons; should we ban
wrenches? Those who had already made up their minds couldn't or wouldn't
hear that argument.

This argument alone wasn't a major desideratum in Ada's failure to
become more popular, but then neither was any one of Richard's
arguments. All of these arguments taken together, though, were too much
at the critical time when Ada might have succeeded as intended.

Too bad.

Art Evans

It would make a fascinating book.

news:uy7nucb8e.fsf@stephe-leake.org...
One of the long-forgotten success stories in Ada was at Xerox, another
company that has a history of grabbing defeat from the jaws of victory.

A team of developers at Xerox decided to use Ada for the software on
a new Xerox copier.   The project was a resounding success and every
team member was enthusiastic about the potential for software on other
Xerox projects.   There were analyses showing how Ada was more
cost-effective than C or other alternatives.  It looked as if Ada might
have found its niche in commercial software development.

Not so.  In spite of all the evidence in support of Ada, some idiot
higher up in management decreed that all software must be written
in C.   He had no understanding of Ada.  All he knew was that it
was a DoD language and he wanted no part of it.

This story has repeated itself over and over.  As noted, a lot of people
are reluctant to use a language designed for "killing and maiming."  It
is silly, of course, but programming aptitude has never been a good
predictor for sensible decision-making.

There is a shortage of Ada programmers, so Lockheed-Martin made
the decision to use C++ on some of our major weapon systems. Not
a particularly wide decision.    They have discovered that, for the software
to be dependable, they must cripple C++ to the point where it is being
used as a "better C" and they have lost all the alleged benefits of C++
except one:  the larger population of university-trained C++ programmers.

Academia has been no better.  As long as the DoD funded projects related
to Ada, professors were happy to take the money.  Once the funding vanished,
those professors redirected their efforts to projects using newer whiz-bang
languages that looked good when they submitted papers for publication.

I recently had the opportunity to teach a beginning class in Java.  What I
discovered is that Java is not type safe, and includes a lot more opportunities
for programming errors than Ada.   It is not any better designed than Ada,
but it does have a lot of libraries.  Most important, it is easier to get a
paper
published if it mentions Java than if it mentions Ada.  A few years ago I was
invited to submit a paper to a conference by the conference chairperson.  I
was told not to mention Ada.

For a variety of reasons, there is a lot of ignorance and bias regarding Ada and
it will not be easy to overcome.   One bright spot is that SPARK has achieved
a high level of respectability and SPARK is an Ada-based environment.

Richard Riehle

Hi,

On 22 Jan 2007 21:53:32 -0800 artifact....@googlemail.com wrote:

I would like to throw in yet another possible reason(*) for Ada being
not popular (within the free software folks).

Currently, the only non-restricted free Ada compiler is FSF GCC/GNAT.
However, the GCC development team doesn't consider Ada to be
a release critical language, so it gets less love whenever a new GCC
is released and its quality is sometimes lower than C and C++ parts
of GCC. In addition, Ada part of GCC supports far less platforms than
C and C++ parts. (**)

So, lets imagine that you are a lead developer in an open source
project (***). One of your goals is to produce software, which will
run atleast on following systems:
 * Debian GNU/Linux 3.1: i386, IA-64, ARM, PowerPC, SPARC, MIPS
 * OpenSUSE 10.2: i386, x86-64
 * OpenBSD 4.0: i386, AMD64, ARM, PowerPC, SPARC
 * FreeBSD 6.2: i386, AMD64, Alpha

The question is: Which programming language do you choose?

Ada is ruled out, because of its limited support for non-mainstream
free operating systems.

-Tero

(*) Actually, only a guess
(**) For example, platforms like OpenBSD/{arm,sparc,ppc,amd64} are
totally unsupported.
(***) Like KDE, Subversion, GTK+, or Sendmail

Much of what others have posted is good, but I also see:

Most developers (98% in my experience) are coders. Coders like languages
like C that let them  code. Then then enjoy spending more time debugging
then they did coding.

The other 2% are SW engineers. They like languages like Ada.

Obviously, C and its ilk are going to be more popular than Ada.

An excellent reply. Ada was also ahead of its time. Computers in 1983
really weren't up to the demands of Ada.

There's always the question of why, given TP's widespread popularity, C
became more popular.

Actually, the DEC Ada compiler of 1984 was pretty good.

Windows 95 was the 1st widely used OS with support for tasking. Ada (95)
was the only widely available language with support for tasking at the
time. We probably lost a good opportunity to gain more acceptance of Ada
by not including a standard windowing library and promoting Ada as the
best language for taking advantage of Win95's features.

More programming is done in COBOL than any other language.

These people never seemed to be very concerned about the DOD's
involvement in COBOL, either.

No one should be hiring X programmers. For long term employees, you
should be looking for SW engineers, whom you then train if necessary.
Identifying SW engineers isn't easy, but one clue is that SW engineers
generally like Ada once they've been exposed to it.

This approach has long term cost savings, as Ada results in SW that is
ready for deployment sooner and has far fewer post-deployment errors
than SW in C. Your SW is ready before your competitors, and is higher
quality.

Plus, your employees, liking Ada, won't be leaving to do C for your
competitors.

Jeffrey R. Carter a écrit :

How true! But sadly far from the common practice :(

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Actually, I don't think that that's a result of Ada not being a
release-critical language for GCC.  I rather think that that's a
result of too few people contributing to the Ada part of GCC, which is
itself a result of too few people using Ada.  Chicken and egg,
catch-22.  But that also applies to other software; for example
OpenBSD's ports collection is much smaller than Debian's or FreeBSD's;
why is that?

As a counter-example, Aurélien Jarno single-handedly ported GNAT to
GNU/kFreeBSD, which is hardly a mainstream platform.  His patches,
initially available for several versions of GNAT, are now in the
Debian packages; you can review them if you like to get a feeling of
how hard it would be to support, say, OpenBSD.

I believe that it was Samuel Tardieu who contributed the sparc-linux
port back in the 3.13p or 3.14p days, but I may be wrong on this.

If your project consists of general-purpose libraries and you want
them available to as many developers as possible, then your best
choice is C; not only because of compiler availability because, more
importantly, because C makes it easy to call your libraries from other
languages.  It is a design goal of GNOME, for example, to support many
languages for application development, and that's why the GTK+ and
GNOME libraries are implemented in C, despite the fact that they are
object-oriented and so would have benefited from an object-oriented
language.

--
Ludovic Brenta.

Lots of people also seem to pounce on the latest hype, thinking that latest
equals greatest. (I suppose that's what makes up a hype.) Those who realize
that C has serious problems typically hope for a new language to solve
those problems. It doesn't seem to occur to them that the problems might
have already been solved in some existing language. At least that's the
impression I get.

--
Björn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

1. Ada-83 simply sucked.  Expensive, inexpressive, with poor libraries
and no support for writing desktop applications.  Ada-83 was designed
for embedded development, and was OK for that purpose, but it was
hopeless for writing hosted applications.

2. For the same reason that Esperanto isn't more popular.  Ada was
designed by a committee to meet theroetical needs.  Most popular
languages have evolved to meet practical needs.  They grew from humble
beginnings to widespread acceptance.  Theoretically, they may be
abominations, but they get the job done.

3. For the same reason that Limburger cheese isn't more popular.  Most
programmers who have tried Ada didn't like it.  What makes a programmer
like a new language?  Usually, someone comes along and says something
like "Remember that program that we spent two weeks writing in C?
Here's a Perl implementation that I put together in three hours and
one-tenth the code."  That's never happened with Ada.

I think this is critical.  Why can't we just say:

with stdio;

pragma import (C, stdio, "stdio.h");

and be able to get structs, functions, constants, variables from C in
an obvious and reasonably reliable way?

Much of what is in C has direct analogs in Ada.  Some of it is via
fiddly #defines, but even a useful subset of these would be e

And of course compilers should spit out header files on request
matching an ada package via the "obvious" rules, so you can
#include it from C.
--
Adrian

                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

FUD!!

http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html

"Jeffrey R. Carter" <jrcar...@acm.org> wrote in message
news:WYtth.318145$FQ1.108931@attbi_s71...

Several decades ago, that was definitely true, but is it /still/ true today?
If one measures things by job openings, then COBOL appears to be outpaced by
C++, Java, and C#.