Why not Ada? followup

Why not Ada? followup

[Michael Shapiro]

In February I issued a request on comp.lang.ada which I excerpt
below.  Since then, I've received many responses.  I've
excerpted many of these below, omitting those which merely
insulted Ada or chastised me for asking the question.  Also the
responses from some defenders of Ada, who didn't seem to read
the question carefully.  The responses are in roughly the order
they reached me.  I have taken the liberty of correcting a few
typographical errors.

If you have additional thoughts, please send them to me.  If I
receive more different ideas, I'll report them.  Feel free to
build on these comments, if you wish.  But please refrain from
attacking them.  Read my question again.  I'm not asking "Why
not use Ada?" but rather "Why do people say they don't, won't,
or can't use Ada?"  I'm looking for perceptions of Ada, not hard
facts, opinions, or arguments.

             Michael

========================================================================
                       The original question
========================================================================

I'm trying to collect reasons (serious, snide, humorous, humorless, etc.)
on why people say they don't, won't, or can't use Ada.  Please e-mail
your responses to me.  I'm trying to put together a paper, of which this 
will form part of one section, on perceptions of Ada's place in our world 
of computing.

 . . .

I already have some reasons, so I don't need repeats of them:
- Ada's ten years old and hasn't kept up with modern programming 
  methods.
- Ada's too {big, clumsy, complicated, hard to learn}.
- Our people already know how to program in {C, C++, Modula, Pascal, ...}
  and it would be too {expensive, time-consuming, difficult, ...}
  to have them learn another language.
- Ada compilers are too {expensive, time-consuming, difficult, ...}.
- Real programmers don't use Ada!

========================================================================
                           Some responses
========================================================================

Mixed language development is not too easy with Ada. For example,
there is a binding (Meridian, I think) between Ada and MS Windows, but
one needs to have Microsoft compiler & linker - so why bother with
added risk (Ada -> C instead of C or C++ and C)? Or Ada and X together
- if the discussions seen here in the net are realistic, the
combination appears to be somewhat risky.

So, basically, to be able to use all the code I find, I'll stick to C
or C++ - there is a good chance that I can call C from other languages
and other languages from C (well, Ada could be a problem, but since
the amount of useful Ada code around is near zero, this is not an
issue).

Bottom line: Ada supports reuse in principle, but not in practice.

========================================================================

We have a complex product line based on more than 10,000,000 lines of C code.
Our products involve heavy software reuse.  Mixing language systems at this
point is considered to be risking too much future support cost for what is
considered an unproven benefit.

========================================================================

In order to do just one little thing, too many lines of code are needed.
Packages are too confusing for newbies.
Strong typing really confuses them, especially explicit type-casting.
Other languages are better for small (under 1000 lines) programs.

I think other people don't like Ada because it doesn't support hacking.  If
a language doesn't let you do stupid things, then it also doesn't let you do
clever things.

========================================================================

When I think of C, I picture in my mind's eye, a red Ferrari roadster.
Ducking in and out of traffic, accelerating away at will, stopping on
a dime.

Then I think of Ada, and I the picture turns to a Peterbuilt standard
cab, dark blue, pulling an overlength chrome trimmed trailer.  Very
powerful due to its Cummins Detroit 8, but lumbering in its enormity.

Two vehicles, alike, yet different, both going to same place, doing it
differently.  Each with its own unique abilities.

I believe programmers are more artists than engineers.  And artists would
rather create their own work instead of painting by numbers.  I think C
provides that freedom.  They can accelerate away at will and stop on a dime.
Ada would have them painting with a brush too complicated to hold.

========================================================================

   -  Ada development tools are expensive, and less common.  

      Most programmers like to do some personal programming.  For this, 
      they often have to go out and buy their own compilers, etc.  I 
      have a Macintosh at home.  Yes, there is an Ada compiler for it.
      No, it won't allow me to compile Hypercard functions like any Mac
      C compiler will.  There are no Interface builder tools for it --
      you have to code the user interface by hand.

      Until folks can use Ada in little projects easily, they won't be
      comfortable with it.  So when you tell the programming team that
      'we're going to use Ada', expect some resistance.  They use C for
      practically any other programming that they do, and would rather
      stick with what they are familiar with.

========================================================================

The one I like the most was by a C person when discussing the strong
type checking of Ada. He referred to the "FASCIST Ada compiler."

========================================================================

Borland has not yet released TurboAda

There is no clear perceived advantage to using Ada. Few can answer the
question "What can I do in Ada that I can't do [better] in my favorite
language?"

Ada doesn't do some things very well or at all. Things that people think
they need to do. 

Ada isn't C++.

DOD had something to do with Ada.

========================================================================

I have used Ada for some projects, and we use Ada for most of
our applications, but I must say I don't trust Ada. A numerical
algorithm written in C and Ada often result in a different result
in the two languages. C doesn't have to convert, convert,
convert.... each time you do a calculation, Ada does and
sometimes this results in a round-off error in intermediate
results, giving erroneous final results.
Try taking an integer, convert it to a FLOAT, do a lot of trig.
functions and get a result. Then reverse the calculations and
see if you get the original integer back..., in C you do.

========================================================================

You may already have this one but I'll add my 2 cents worth. When I was
looking around for a PD Ada compiler to play with I found none! I heard
about the compiler project at NYU (I know it was one of the NY Colleges) but
I was lead to understand that that particular project was still a long way
from completion. In my collection of languages (This is for a Macintosh no
less) I have PD, SW, or low priced commercial versions of: Pascal, C, Lisp,
Scheme, Forth, Prolog, Oberon, and at least a half a dozen other languages.
The most expensive of which is the c compiler that I bought from Semantic.
On the IBM side I have every imaginable PD/SW languages but no Ada.

This letter is getting a little incoherent. My point is that whenever I
have gone looking for a compiler to experiment with a new language I have
always been able to either get it free off the net or to get it for a
nominal fee (nominal < $100). If the industry wants Ada to succeed then
we need to see as many free Ada compilers as there are good free (or at
least inexpensive) c and Pascal compilers.

Well, that's my thinking on the matter. If you know of a *good* Ada compiler
for either the Mac or IBM (Mac toolbox or Windows interface would be nice) I
would like to know of it.

========================================================================
 
1. Expensive compilers. - A C compiler costs around $2000 on a Sun, but
      the Ada compiler costs $10,000.
2. Speed - I can compile and link my C program in 30 seconds, but it
      takes 5 minutes to do the same with an Ada program.  This really
      slows down the development process.
      
Don't get me wrong.  I really like Ada.  I see these two things as
really discouraging when using Ada.  As for speed, a solution would be
for someone to make an incremental compilation environment.  Something
as fast as LightSpeed C on the Macintosh would be great.

3. Better code generation. - 

========================================================================

Ada compilers don't generate sufficiently efficient code, or sufficiently
small code.

========================================================================

- Several of reasons you give (too expensive, already know other
  languages) are part of it.
- Availability of compilers -- I've worked with embedded systems and
  Ada compilers don't seem as available.
- Leveraging off popular software.  I've done quite a bit of C on the
  80186 for embedded systems.  I started with a cross compiler running
  on a VAX.  We got much better support when we moved to PCs since we
  could use a popular compiler (Turbo C).  Bugs, problems, etc. have
  higher priority when they deal with the mainstream product.  On the
  VAX updates were always a couple months later than PC versions.  In
  the case of Ada the relatively small user community means the
  product probably isn't as well tested or mature.
- The code generation of popular C compilers (where there was a
  competition for better optimization) was always marginal on the PC.
  I doubt the Ada compilers would be better in a more or less captive
  market.
- Perception of the language -- I don't think I could sell Ada, most
  programmers I know prefer the looser type checking of something like
  C.


There are several characteristics of the language I'm not fond of.
These are also true of many other languages, and I don't claim to know
a better alternative in all cases.  I list a couple examples (note
these aren't Ada specific but also exist in various other languages).

- The type system of Ada doesn't match the real world (though for that
  matter, neither do the type systems of Modula 2/3, Pascal, etc.).  If
  I move to a language with strong typing I'd rather have it work with
  me, not against me.  Unfortunately I don't know of anything other
  than small experiments in having the type system match the values
  being represented.
- I prefer a structure which minimizes duplication of information,
  while my experience with languages having a separate package and
  package body is that duplicating declarations gets in the way.  See
  Eiffel for an example of how to do things without duplication
  (though I'm not fond of the separate "export" clause in Eiffel
  either).
- The lack of overloading of assignment and funny rules for
  overloading equality mean one can't create easy to use user defined
  data types.  Instead user defined types are second class to built in
  types (e.g. assignment must be through some sort of "assign"
  procedure instead of via :=).  I prefer C++, where I can define a
  data type which can be used in the same way as a built in type.

In summary, Ada is a good language for software development, and Ada
9X will probably improve on this.  However I don't see enough
advantages to try to get it used.  If I were in a job where Ada was
used I would, otherwise I'll stick with the best language and
implementation for the job, which hasn't been Ada in the past.

========================================================================

  My OPINION... of why people don't use Ada is because people
  are by nature (generalizing a lot here) lazy.  Ada doesn't lend
  itself well to quickly throwing something together and trying it
  out.  It's easier to use if you have a well thought out "thing"
  you want to "build" and want the best quality "stuff" to build it
  with.  Ada forces you to be neat (even when neatness is not critical)
  here I'm talking about not letting you readily multiply things of
  different type readily unless you specially convert everything.
  I think you can see where I'm coming from... all those other reasons
  (except the last one) are of course valid in some cases and may
  contribute to my perception of part of the problem.
          Keep in mind I'm not a software
          engineer or a programmer but I
          have taken courses in Ada and SW
          engineering...  Definitely not
          an expert... just someone with an
          opinion.

========================================================================

>- Ada's ten years old and hasn't kept up with modern programming 
>  methods.
Hmm... FORTRAN and COBOL are both over 35 years old and they have
done quite well at "keeping up" (although not perfectly).

>- Ada's too {big, clumsy, complicated, hard to learn}.
Awww...

>- Our people already know how to program in {C, C++, Modula, Pascal, ...}
>  and it would be too {expensive, time-consuming, difficult, ...}
>  to have them learn another language.
But a carpenter already knows how to use a hammer, it would be too
{expensive, time-consuming, difficult, ...} to have him learn how to
use a screwdriver too!
The more tools you know how to use the more options you have available.

>- Ada compilers are too {expensive, time-consuming, difficult, ...}.
That's sometimes a point... but its finally getting less valid.

>- Real programmers don't use Ada!
Real Software Engineers always use Ada, when given a choice.


The only really valid one that I have heard was something like:
You can't get an Ada compiler for the 8031 microcontroller, so we will
have to use some other language for that part of the system.

========================================================================

1. When introduced, the tools were far too expensive and klunky. It was
just a pain in the butt to program in Ada compared to other languages.
Even as time went on, the tools were still too expensive. They were
beyond the reach of college students. Even those who did shell out the
money found the programming environment to be terrible in comparison to
other languages, and _extremely_ slow. If you don't have the newcomers
to the workplace using Ada, it just won't catch on. (BTW - this was Intel's
strategy many years ago. Seed the college community with free or dirt
cheap CPU's for them to use and learn with, and reap the benefits once they
graduate and enter the workforce. And now there is estimated to be over
100 million Intel based PCs!)

2.  Ada was forced down contractor's throats. Everyone will tend to shy
away from anything that is forced on them. DoD came out and said "Here
is Ada. It is wonderful. You WILL use it." That kind of introduction was
not very welcomed. Instead of requiring its use, DoD would have been better
off dumping a little money into the tools/environment development, and then
presented Ada as a great language to use. Give the "users" tools that are
better than what they are using, a more powerful language, and then say
"OK - make the logical choice. You can use whatever language you want."
Given the right tools and education, there would have been more that chose
Ada. And once momentum builds, its hard to stop.

========================================================================

At the moment, because :-

   - Ada compilers are too expensive.

Where "too expensive" for the most part means "not free" (given that
for almost any other language I can ftp a decent system for free).
\x1a

\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a\x1a
\x1a\x1a\x1a\x1a\x1a\x1a\x1a

--                    
INTERNET:  mshapiro@netlink.cts.com (Michael Shapiro)
UUCP:   ...!ryptyde!netlink!mshapiro
NetLink Online Communications * Public Access in San Diego, CA (619) 453-1115

Re: Why not Ada? followup

[Richard A. O'Keefe]

In article <Jk6c1B2w165w@netlink.cts.com>,
mshapiro@netlink.cts.com (Michael Shapiro) excerpted
something that had been sent to him:
> ========================================================================
> I have used Ada for some projects, and we use Ada for most of
> our applications, but I must say I don't trust Ada. A numerical
> algorithm written in C and Ada often result in a different result
> in the two languages. C doesn't have to convert, convert,
> convert.... each time you do a calculation, Ada does and
> sometimes this results in a round-off error in intermediate
> results, giving erroneous final results.
> Try taking an integer, convert it to a FLOAT, do a lot of trig.
> functions and get a result. Then reverse the calculations and
> see if you get the original integer back..., in C you do.
> ========================================================================

The following rave against Ada was that there was no free Ada compiler.
Typical of the raves against Ada, that one relied on demonstrably false
hearsay.  (There _is_ a finished Ada compiler from NYU that is free.
I use it.  It's described in the comp.lang.ada FAQ posting.)

But this one about numbers has me completely bewildered.
Ada _has_ a floating-point model which an implementation _must_ adhere to.
C does not.  I have, and frequently study, the ISO C standard.  There are
NO useful guarantees about floating-point arithmetic in that standard.
There _are_ some useful guarantees about floating-point NUMBERS in the 
description of <limits.h>.  My point is that ok, you are guaranteed that
(double) has at least 10 decimal digits worth of precision, but you are
NOT guaranteed that addition preserves even one of those digits.
Again, what's all this b***s**t about convert, convert, convert?  If I
have
	x, y, z: some_floating_point_type;
	x := y+z;
in Ada there is no conversion required.  On the other hand, if I have
	float x, y, z;
	x = y+z;
in C, the standard _does_ mandate 3 conversions; it's equivalent to
	x = (float)((double)y + (double)z);
and a compiler writer is only allowed to do the addition in single
precision if s/he can prove that it makes no difference to the final
result.
And the third claim is quite literally incredible.  One reason that I
don't believe it is that I _have_ tried that kind of computation in C
and no it _doesn't_ work.  In general, of course, it couldn't possibly
work.  Proof:
	x = asin(sin(1.0 * N));
Anyone with even the most meagre grasp of numerical analysis will understand
why
	x = tan(atan(1.0 * N));
cannot be expected to work for all integers,   In fact, I tried it just
know using GCC 2.2.1 on an Encore Multimax, which has IEEE-754ish arithmetic,
and found
    n = 1, atan(n) = 0.785398, tan(atan(n))-n = -1.11022e-16
"Reverse the calculations and see if you get the original integer back."
In C you *don't*.  (And can't.  double != real.)

So this criticism of Ada boils down to "someone who relies on hearsay and
hasn't bothered to test his assumptions about C either and doesn't understand
computer arithmetic thinks that Ada has worse arithmetic than C."  Many of
the other raves were equally ill informed.

There _is_ a valid criticism which could be brought against Ada.
The Fortran standards (F66, F77, F90), the Algol standards (A60.1, A68),
the Pascal standards, and C all of them include trig functions.  The
Ada83 standard doesn't.  (Which means, in practice, that many Ada systems
offer bindings to the same library that C uses, which makes the rave above
even sillier.)  A lot of work has gone into defining trig (and other)
functions for Ada, and I would _love_ to have something that met the draft
spec I saw a while back.