Re: Top 10 Ada myths

Re: Top 10 Ada myths

[Paul Pukite]

Vladimir Vukicevic wrote:
> Speaking of why people think Ada is not a good language... it'd be nice
> if someone collected the many myths about Ada, and collected them all
> together for distribution to the unbelievers. :-)

Per your request...

        Top 10 myths and misconceptions about Ada
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

10. Myth: Ada is too complex and large a language.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    False. Some people look at the detailed language reference manual and 
    equate a well-specified language (Ada) with that of a complex language.
    In fact, recent surveys show Ada to be the second most popular
    language, after Pascal, for first-year computer science courses.
    And with the current situation of cheap computing power, Ada is 
    definitely NOT too large to implement.  For example, a typical 
    Ada Windows+DOS compiler requires just a few Megs of disk space.

 9. Myth: Ada costs too much.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    False. If you include features automatically supported with Ada, 
    such as lint checking, range checking, etc. that normally require 
    add-on tool support for other languages, the costs become comparable.  
    Besides, GNAT Ada is free, comes on many different platforms,
    and is starting to be used in embedded systems. 
    (...in any case, doesn't a programmer cost at least $50K a year?)  
    
 8. Myth: Isn't Ada associated only with the military?
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    No.  It was originally sponsored by the DoD and in use by various
    military organizations.  However, just like the Internet, VHDL, 
    Berkeley UNIX and several other DoD-seeded projects, it has outgrown 
    its roots; and Ada can now be considered an international 
    commercial language.
     
 7. Myth: Can't use it for small applications.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    False.  In fact, Ada _scales_ in use from the smallest desktop 
    application to the onboard software of the largest aircraft (including
    the Airbus 340 and the Boeing 777).
    
      -- A complete Ada program to output "Hello World"
      with Text_IO;
      procedure Hello is
      begin
         Text_IO.Put_Line("Hello World");
      end Hello;
    
    Now, is that small enough for you?
    
 6. Myth: It doesn't allow me any programming freedom.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    False. You can actually have all the flexibility you want, but with 
    Ada you will likely have to call attention to the implementation-
    specific sections of code.  Remember that maintenance, portability, 
    and team-programming are essentials elements of an Ada design.
    And if you want, you can _always_ interface Ada in a standard way to 
    any other language (C, C++ classes, DLL (Ada DLL too!), Fortran).

 5. Myth: Ada is not a popular language.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Not true. You would be surprised at who uses Ada. Important 
    applications include air traffic control, communications satellites, 
    commercial airliners, TGV, many cities' subway systems,
    and many other big projects that don't get a lot of publicity.
    
 4. Myth: Ada is for wimps (or words to that effect).
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    I don't have a good explanation for this one.  Is it the name Ada? 
    Or maybe that Ada programming is not associated with software hackers,
    many of whom actually _enjoy_ spending time debugging obfuscated code?
    Actually, Ada programmers don't care what they get called, as long
    as they can continue to compile working programs the first time 
    through without needing to invoke a debugger.
    
 3. Myth: Too verbose.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    As a means of documentation, Ada was designed to be easier to read 
    than to write.  In fact, entering code occupies only a fraction of a 
    programmer's time while the enhanced readability will pay for itself 
    when maintenance is needed.  If you don't believe this, I hope no 
    one has to read your code in a few years (including guess who?).  
    
 2. Myth: Too slow, and executables too large.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    False. GNAT Ada uses the same backend as other GNU-supported languages. 
    Compare for yourself, and you will discover Ada competes well
    with the other high performance languages.  And if you really feel 
    the need for speed, Ada tasking maps transparently to the new multi-
    processor-enabled computing platforms (such as SGI and NT).

And the #1 Ada myth:
    
 1. Myth: Ada is not object-oriented.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    False!  Actually, Ada 95 is the first internationally standardized OO 
    language (ISO, ANSI, FIPS) as it supports the essential features of 
    object orientation -- including full inheritance and run-time polymorphism 
    in addition to the abstraction and encapsulation always supported.
    And...Ada has had exceptions and generic templates for 10 years.


(p.s. thanks to Prof.Feldman for providing extra ammo)

Re: Top 10 Ada myths

[Norman H. Cohen]

In article <51286.pukite@daina.com>, "Paul Pukite" <pukite@daina.com> writes: 
|> Vladimir Vukicevic wrote: 
...
|>         Top 10 myths and misconceptions about Ada
|>         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...

Well done, Paul!

(Another myth worth listing: "Ada was designed by committee."  The design
of Ada 83 is principally the vision of one person, Jean Ichbiah, who had
many expert advisors, but no board of directors voting his decisions up
or down.  The Ada-95 revisions are principally the vision of one person,
Tucker Taft, whose detailed design decisions also benefitted from the
advice, but not the direction, of many advisors, including open groups of
volunteer reviewers.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Top 10 Ada myths

[Chris Reedy]

In article <51286.pukite@daina.com>, <pukite@daina.com> wrote:

> 
>  4. Myth: Ada is for wimps (or words to that effect).
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     I don't have a good explanation for this one.  Is it the name Ada? 
>     Or maybe that Ada programming is not associated with software hackers,
>     many of whom actually _enjoy_ spending time debugging obfuscated code?
>     Actually, Ada programmers don't care what they get called, as long
>     as they can continue to compile working programs the first time 
>     through without needing to invoke a debugger.
>     

Unfortunately, there are too many programmers(?) who think that Ada is for
wimps because they don't believe that writing programs that can be read
and maintained by anyone other than themselves or their immediate cohorts
is an appropriate goal for a programming language (as opposed to getting
as close to the bare silicon as they can).

  Chris

The above opinions are my own and not MITRE's.
Chris Reedy, Workstation System Engineering Center, Z667
The MITRE Corporation, 7525 Colshire Drive, McLean, VA 22102-3481
Email: creedy@mitre.org  Phone: (703) 883-7183  FAX: (703) 883-6991

Re: Top 10 Ada myths

[Robert I. Eachus]

In article <3kc5ig$164a@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:

  > (Another myth worth listing: "Ada was designed by committee."  The
  > design of Ada 83 is principally the vision of one person, Jean
  > Ichbiah, who had many expert advisors, but no board of directors
  > voting his decisions up or down.  The Ada-95 revisions are
  > principally the vision of one person, Tucker Taft, whose detailed
  > design decisions also benefitted from the advice, but not the
  > direction, of many advisors, including open groups of volunteer
  > reviewers.)

     Jean Ichbiah did have a couple of "Boards of Directors" which
could and did try to exert control over the direction taken.  But I
remember talking to Robert Dewar during the Ada 83 standardization
effort.  He described a DR vote (on eliminating derived types?) by
saying, "But the vote was eight to Ichbiah, so it will probably be
reversed."

     The same thing happened with Ada 95.  When Tucker Taft didn't
like the "advice" he was given by the DR's or WG9, he came back with a
better idea or a better explanation.  So the guiding hand behind the
Ada 95 revison has always been Tucker's, and AFAIK, there is no part
of the language which Tucker has reservations about. (Of course, the
moment anything in this field is "finished," you find errors and bugs.
But Ada 95 has been much, much better than Ada 83 in this regard, and
Ada 83 was better than most published langauge standards.)

     


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Top 10 Ada myths

[Mats Weber]

In article <EACHUS.95Mar20113605@spectre.mitre.org>,
eachus@spectre.mitre.org (Robert I. Eachus) wrote:

> [...] (Of course, the
> moment anything in this field is "finished," you find errors and bugs.
> But Ada 95 has been much, much better than Ada 83 in this regard [...]

How do you know ? There isn't even a complete compiler around. I think
certain bugs in the Ada 95 definition will only come up as the language
gets implemented.

Re: Top 10 Ada myths

[David Weller]

In article <Mats.Weber-2003952122500001@mlma11.matrix.ch>,
Mats Weber <Mats.Weber@matrix.ch> wrote:
>In article <EACHUS.95Mar20113605@spectre.mitre.org>,
>eachus@spectre.mitre.org (Robert I. Eachus) wrote:
>
>> [...] (Of course, the
>> moment anything in this field is "finished," you find errors and bugs.
>> But Ada 95 has been much, much better than Ada 83 in this regard [...]
>
>How do you know ? There isn't even a complete compiler around. I think
>certain bugs in the Ada 95 definition will only come up as the language
>gets implemented.

Ouch!  Jeez, Mats.  Robert is one of those guys who eats, sleeps, and
breathes Ada (if I recall correctly, he also has a somewhat annoying
habit of quiting chapter, section, and paragraph from memory :-).

While I think your statement holds a kernel of truth, I'm very
inclined to believe Robert's comments (of course, that doesn't stop
me from prying into different parts of the language to see what's
broken :-)


--
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
		if u cn rd ths, u r gd enuf to chg to Ada   :-)

Re: Top 10 Ada myths

[Robert I. Eachus]

   (I said):
   > [...] (Of course, the
   > moment anything in this field is "finished," you find errors and bugs.
   > But Ada 95 has been much, much better than Ada 83 in this regard [...]

In article <Mats.Weber-2003952122500001@mlma11.matrix.ch> Mats.Weber@matrix.ch (Mats Weber) writes:

   > How do you know ? There isn't even a complete compiler around. I
   > think certain bugs in the Ada 95 definition will only come up as
   > the language gets implemented.

   I know how many "known bugs" there were in the 1983 RM 12 years
ago.  I could argue that the 1995 standard has been more widely
available than the Ada 83 standard was at this point in time, but I'll
assume that the degree of review has been equal.  By this time in
1983, several it's too late to fix its were known, and some problems
which were to give the ARG fits for years had been recognized.

   You could contend that there are some "known problems" with Ada 95
that will turn out to be thornier than they seem, but I don't see any.
And the only "too late to fix" that I know of are the rules for
deriving from types with constructors.  (Yes, yes, the Ada 95 design
is very nice and workable in this area, and it is much more powerful
than some of the alternatives considered.  But it confuses people, and
I expect to spend the next ten years explaining those rules.  However,
in Ada 83 there were several issues in that category by this time.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Top 10 Ada myths

[Robert Dewar]

Actually the real history of derived types is as follows:

In an attempt to simplify the Ada 83 definition, the DR's discussed the
possibility of eliminating derived types. Note that in this connection:

  type x is range 1 .. 10;

is not a derived type (in fact Ada 83 remains confused over whether this
is or is not a derived type declaration, although in Ada 95, it definitely
IS a derived type declaration).

At a meeting which Jean did not attend, the DR's voted unanimously (as
I remember with no abstentions) that derived types should be removed.

JDI was pretty horrified, since he felt that DT's were a basic building
block of the language, and vowed never to miss another DR meeting (Tuck
never missed a 9X DR meeting, so I guess he took this experience to heart
too :-)

At the next meeting, we again discussed derived types. I am operating from
slightly rusty memory now, but my memory was that the vote was N-2, with
the 2 being Jean and Lee McLaren, who I remember very well saying "I can't
think of any use right now of derived types, but I might well think of some
use later on, so I don't want to eliminate them now".

And there it stood, but nothing happened. Some months later I was in the
AJPO director's office (I am pretty sure it was Bill Carlson at the time, but
these memories do get jumbled). I asked him what happened to DT's. He said
that Robert Firth had found some fundamental objections to their removal.
That seemed strange, so we called Robert in England, and his reply was
roughly "No, I can't think of any fundamental objections, but I think
we should keep them in, for one thing they look like they will be lots of
fun to implement" or something like that (and ther definitely should be 
a smiley on that quote)!

Anyway they stayed, and basically they stayed because JDI insisted that
he felt they were critical, and he held the pen. There weren't many issues
on which battle lines were drawn quite so clearly, but this incident is
interesting because it sure puts the lie to the notion of design by
committee. 

And it is interesting that derived types have now become the fundamental
basis for adding object oriented stuff in Ada 95 :-)

For Ada 95, again, although we had a committee, or really two (the DR's and
ISO WG9), Tuck kept a very firm hand on the design. THat is not to say he
didn't listen to input, from the committees and from the world, this was
a *very* open process. It is also not to say that the committees had no
effect. 

Both the DR's and WG9 had a much more conservative view of what should be
added to Ada 83 than Tuck, and reacted horrified to the scope of some of 
the earlier suggestions (see for example mapping document version 2). And
there is no doubt that the language was scaled back in response. But this
was still by no means design by committee. On the contrary, the result of
these discussions was to send Tucker back to the drawing board to figure 
out how to retain the crucial shape of his design while cutting back the
scope in a consistent manner.

In retrospect, although it seemed a bit of an energetic tussle at the
time, I think the dynamics resulted in a very successful final design.
If Tuck hadn't pushed the envelope, I think the conservative inclinations
of the DR's would have resulted in something MUCH too timid (there were
quite a few people who felt that minor tweaks to Ada 83 would be sufficient).
On the other hand, I think if the committee had not pushed to keep things
simple, then we would have ended up with something much too complex.

Certainly no one could describe the process as design by committee! Both
Ada 83 and Ada 95 were designed by teams with captains, and as I once
said in a letter to Government Computer News, when Dave Parnas trotted
out the usual "designed by committee" complaint, any sports fan knows
the difference between a committee and a team!

Robert

Quoting the RM (was Re: Top 10 Ada myths)

[Robert I. Eachus]

In article <3klbqm$fkc@Starbase.NeoSoft.COM> dweller@Starbase.NeoSoft.COM (David Weller) writes:

 > Ouch!  Jeez, Mats.  Robert is one of those guys who eats, sleeps, and
 > breathes Ada (if I recall correctly, he also has a somewhat annoying
 > habit of quiting chapter, section, and paragraph from memory :-).

   I never knew I quit chapters. ;-)

   Seriously the trick is that, just like the Bible, there are a few
key paragraphs that come up over and over, and after the fifth or
sixth time you can (or at least I can) recite the paragraph and the
citation in your sleep.  (Not that I'm always asleep when I read
c.l.a., but sometimes it seems that way.)

   Hmmm. It would be fun to come up with list of the top ten citations
in Ada 83 for the FAQ...11.6(7) "A predefined operation need not be
invoked at all..." must be number one.  3.6.1(2) (for I in -1..10
doesn't work) is up there but no where near as popular as in early
years.  Five to seven years ago 9.6(1) "...for at least the duration
specified..." was near the top.  Any other votes for first place?

   In Ada 95 on the other hand most of these "you know what we mean"
problems are gone.  Answers to questions about the standard often
involve the interaction of several sections, but they are fairly
clear.  The ONLY reference I have so far memorized in Ada 95 is
3.9.3(4-6), which is where you find that derived subprograms with a
controlling result are abstract, and must be overridden.

    I don't know why those paragraphs don't sink in, but it seems you
have to explain why it is important (constructors always must be
overriden if they are dispatching) before people remember it.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Top 10 Ada myths

[Robert I. Eachus]

In article <3kngjg$g4u@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

  > Actually the real history of derived types is as follows:

    As I said, I couldn't remember exactly which issue the quote was
in reference to, it was in the middle of a list of current open
issues, one of which was derived types.

    But as you clearly indicted, and I was trying to communicate as
well, all the committees did--and did very well--both times was to
help one person put together a coherent integrated language that
satified a very large menu of requirements.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Top 10 Ada myths

[Robert Dewar]

My perspective is quite different from Robert Eachus's

I don't agree that the 1983 standard had lots of known holes

I think the 1985 standard has more holes than he thought

but in both cases we are talking about quite tiny holes. I think we will
find that there are lots of small problems to keep the ARG busy. Most 
recently, I have been discussing the rules for inheritance of the
stream attributes on tagged types, and it seems like they are completely
broken. Just one small example.

Here is another interesting question that just occurred the other day.

What is the relation of the standard files for Text_IO and Wide_Text_IO?
THey appear to be quite distinct. That seems to mean that if you with
Text_IO and Widfe_Text_IO in the same program you have automatically
an instance of file sharing, which may simply not work ..... ???

As I say, I think the new ARG will have plenty to keep it busy!
\x1adp

Re: Top 10 Ada myths

[Robert I. Eachus]

In article <3kr29h$grh@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

 >    My perspective is quite different from Robert Eachus's...but in
 > both cases we are talking about quite tiny holes.

     I don't think we disagree.  The holes in the language--as
understood by the ARG--may not be that different.  But there are a
number of cases in Ada 83 where Jean Ichbiah decided that putting all
the special cases and restrictions in the Reference Manual would
seriously damage its readability.  A significant number of these cases
ended up spelled out in AIs.  Others just entered the folklore--the
Goodenough trick for overloading equality, the fact that it is
possible to inherit entries--but only if they are renamed as
procedures, etc.

     In Ada 95, the approach is different.  Tucker did a very good job
of putting all the rules in the RM, and much of the elaboration needed
to understand the rules in the annotated version.  As a result, the RM
is somewhat less readable than in 1983, but those who do read it come
away with many fewer misconceptions.  Since the rationale is not only
very readable, maintained and printed in parallel, I think that the
net effect of the 95 approach is a major improvement.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Readability of manual (was Re: Top 10 Ada myths)

[Dan Johnston D.B.]

In <EACHUS.95Mar23115217@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:

>     In Ada 95, the approach is different.  Tucker did a very good job
>of putting all the rules in the RM, and much of the elaboration needed
>to understand the rules in the annotated version.  As a result, the RM
>is somewhat less readable than in 1983, but those who do read it come
>away with many fewer misconceptions.  Since the rationale is not only
>very readable, maintained and printed in parallel, I think that the
>net effect of the 95 approach is a major improvement.

It appears to me (as a reader only) that there is a difference in the
intended audience.
  The Ada 83 manual seemed to be directed towards the programmer, whereas
  the Ada 95 manual seems to be directed towards compiler writers and
tool developers.
   I found the Ada 83 manual quite readable. When programming, if I had
doubts I could generally go to the manual and find what I wanted. (This was
helped, I believe, by the fact that the compilers I used generally reported
the number of the reference manual clause in the error messages.)  On the
other hand, with the Ada-95 manual, I find it very difficult to find (and
then understand) the rules.  The gnat error messages are generally good
but they don't help find the relevent rules in the manual.
   I don't believe that either the rationale or a text book is a substitute
for a good manual.  Perhaps if I could get a copy of the annotated manual
it might help. (I have ftp'd it but unfortunately it is too large to print
on our system.)  I know that a lot of programmers like to learn from
examples but I don't find that adequate by itself and like to see the rules.
  I know my brain has slowed down in the intervening 10+ years but I would
have hoped that a good knowledge of Ada-83 would have compensated for that
in trying to read the Ada-95 manual.
  Perhaps the origins of Ada-83 in the competitive design process (Green vs
Red etc) was an influence in making its manual more readable.
     dan.      Dan Johnston, Dept of Comp Sci, Uni of Queensland, Australia.
                    dan@cs.uq.oz.au