Re: Papers saying Ada as an overly complex language and hard to implement

[matthew_heaney@acm.org (Matthew Heaney)]

>Subject:  Re: Papers saying Ada as an overly complex language and hard to
implement
>From: Yongxiang Gao <gyx@cs.utexas.edu>
>Date: 1998/02/18

>Hi, Guy
>    I put the original mail from my boss here. What are you going to say?
>    Don't show off too much.
>Thanks.
>Yongxiang
>
>Simon Wright wrote:
>
>> If you go to a newsgroup on Ada and (effectively) ask the residents to
>> provide you with evidence that they are foolish you can't expect a
>> totally happy response!
>>
>> Did your boss really say (in paraphrase) "Find me evidence that Ada is
>> too complex"? sounds very closed-minded to me! Can't see why one would
>> want such except to compare with other languages, in which case see
>> Robert Dewar's remarks.
>>
>> --
>> Simon Wright                        Work Email: simon.j.wright@gecm.com
>> GEC-Marconi Radar & Defence Systems            Voice: +44(0)1705-701778
>> Command & Information Systems Division           FAX: +44(0)1705-701800
>
> Subject:
>         another TA task
>   Date:
>         Thu, 12 Feb 1998 09:14:53 -0600 (CST)
>   From:
>         Calvin Lin <lin@cs.utexas.edu>
>     To:
>         gyx@cs.utexas.edu
>
>
>
>
>Yongxiang,
>
>    Could you do another literature search for me?  I'm interested in
>papers that explain why Ada is an overly complex language, why it's
>a hard language to write a compiler for, and other problems with Ada.
>
>    Thanks a lot.
>
>                        Calvin
>
>--
>Home: 1633 Royal Crest, Apt.1146, Austin, TX 78741
>Phone: 512-912-0291(H)    512-471-9790(O)
>Email: gyx@cs.utexas.edu  Office: PAI 5.54
>Homepage : http://www.cs.utexas.edu/users/gyx

Here are some articles on the subject of Ada's complexity.  Many are from
the early 80's, when the language was still being standardized.

On the GREEN Language Submitted to the DoD
Edsger Dijkstra
SIGPLAN Notices, Vol 13, No 10, Oct 78, p16-21
- Dijkstra critiques an early version Ada.  Companion articles in the same
issue critique the other three finalists in the language competition

The Emperor's Old Clothes
C. A. R. Hoare
1980 Turing Award Lecture
ACM Turing Award Lectures, 1966-1985
ACM Press
also in
The Ada Programming Language: A Tutorial
Sabina Saib and Robert Fritz
IEEE Computer Science Presss, 1983
- Ada's reputation as a language too big and too complex can be traced
directly back to Hoare's speech, in which argues for an Ada subset.  Hoare
claimed that Ada was an unsafe language not appropriate for use on
safety-critical systems - ironically, the very domains for which Ada was
designed.

"At first I hoped that such a technically unsound project would collapse
but I soon realized it was doomed to success."

"And so, the best of my advice to the originators and designers of Ada has
been ignored.  In this last resort, I appeal to you, representatives of the
programming profession in the United States, and citizens concerned with
the welfare and safety of your own country and of mankind: Do not allow
this language in its present state to be used in applications where
reliability is critical..."

<mailto:hoare@prg.ox.ac.uk>

That speech did permanent damage to Ada's reputation, and spawned a whole
movement to scale back the size of Ada.  However, Hoare does give a
lukewarm endorsement of Ada in the Foreward to David Watt's book:

"The language incorporates many excellent structural features which have
proved their value in many precursor languages such as Pascal and Pascal
Plus....One can now look forward to a rapid and widespread improvement in
programming practice, both from those who use the language and from those
who study its concepts and structures."

Ada: Language and Methodology
David Watt, Brian Wichmann, and William Findlay
Prentice-Hall, 1987

<mailto:daw@dcs.gla.ac.uk>
<mailto:baw@npl.co.uk>


Programs-Simple or Complex
ACM Forum
CACM, July 81, Vol 24, No 7, p475-478
-Letters to the editor defending Ada against Hoare's attacks.  Hoare
himself responds to the letters.  Here's his opening paragraph:

"I am glad Saib finds Ada simpler than Algol 68 and PL/I, but I fear there
is little to support this view.  I cannot accept that the extraordinary
series of technically unsound documents entitled "strawman, woodenman,
tinman, ironman," and the technically inadequate management and review
processes, give grounds for confidence in the quality of the resulting
design."

Hoare later says that "All my advice has been placed in the public domain,
along with the other project documents, and may be freely consulted."  I
have been unable to find these documents.  If anyone knows where I can find
Hoare's original comments, please let me know. --mjh

More Commentary on Ada
ACM Forum
CACM, Nov 81, Vol 24, No. 11, p783-785
- More letters to the editor.  There's a funny one by Roy Nutt (an
appropriate name, I'd say):  "Although not for the same reasons as C.A.R.
Hoare, I too think that Ada is a terrible mistake.  Ada is awful.  Ada is
stupid, clumsy, and arrogant."


Answering an Ada Adversary
David Watt
CACM, Jan 82, Vol 25, No. 1, p80-81
- David Watt responds to Nutt, calling his letter "ill-mannered invective"
and xenophobic.  Even none other than Edsger Dijkstra responds with "I hope
he [Nutt] regrets his paragraph as much as I do."

Pete Wegner writes (in the same column) his Reflections on the Ada
controversy, making poignant comments about Ada's design (see the
references to his other papers).  In a statement that foretold the Ada 95
design:  "Parallels with Algol 60 suggest a revised Ada report by early
1983, and a new version of Ada (say, Ada 88) by 1990."   Oh well, you were
only off by 7 years, Peter!



The ACM Position on Standardization of the Ada Language
Patrick G. Skelly
CACM, Reb 82, Vol 25, No 2, p118-120
- Skelly explains why the ACM Standards Committee rejected the Ada language
for ANSI standardization.  Includes responses from an Ada committee member
(unfortunately not identified; John Goodenough maybe?), defending their
decisions.


Letter to the Ada Canvassees from the DoD
Larry Druffel
CACM, Feb 82, Vol 25, No. 2, p161-162
- Text of a letter sent to members of the Ada Canvass by the director of
the Ada Joint Program Office, "summarizing the outcome of the balloting and
outlining a resulting course of action."


Scaling Down Ada (Or Towards a Standard Ada Subset)
Henry Ledgard and Andrew Singer
CACM, Feb 82, Vol 25, No.2, p121-125
- Argue that Ada should be subsetted, and suggest things to get rid of. 
They were running with the subset idea suggested by Hoare.


Is Ada Too Big?  A Designer Answers The Critics
Brian Wichmann
CACM, Feb 84, Vol 27, No 2, p98-103
- a response to Ledgard and Singer
<mailto:baw@npl.co.uk>


Is Ada Too Big? (letter to the editor)
David Parnas
CACM, Nov 84, Vol 27, No. 11, p1155-1156
- a letter to the editor in response to the Wichmann article


Accomplishments and Deficiencies of Ada
Peter Wegner 
IEEE Software, Jul 84, p39-42
- suggests we ought to "throw Ada away and use what we have learned from
Ada to develop a new well-integrated language, environment, and
methodology"


Comparing and Assessing Programming Languages: Ada, C, Pascal
Alan Feuer, Narain Gehini, eds
Prentice-Hall, 1984
- Has some stuff about Ada.  This book has been out of print, but I found
it an a used bookstore only recently, so I haven't read it yet.


On Understanding Types, Data Abstraction, and Polymorphism
Luca Cardelli, Peter Wegner
ACM Computing Surveys, Vol 17, No 4, Dec 85, p471-522
- A classic paper that I find very abstruse.  Reading it is worthwhile,
though, because it explains Wegner's philosophy of language design, and to
helps you understand the basis of his criticism of Ada.

Learning the Language
Peter Wegner
Byte, March 89, p 245-253
- A more palatable explaination of the design of object-oriented languages;
start with this one before trying to get through Cardelli & Wegner.

Concepts and Paradigms of Object-Oriented Programming (OOPSLA-89 Keynote)
Peter Wegner
June 1990
- Makes the same tired arguments against packages.  "Its notion of type
does not uniformly handle its rich and almost baroque module structure."  I
wonder what he'd say about Ada 95's module structure?!

Wegner's frequent criticisms of Ada seem to be based on the assumption that
the principle abstraction mechanism in Ada is the package; this is why he
labelled Ada an "object-based" rather than a "class (type)-based" language. 
All his papers argue that the package is not a first-class citizen as a
language  construct; for example, it doesn't have a type and can't be
passed as a subprogram argument.  The argument seems to be that since Ada
programming is based packages, and packages aren't first-class language
citizens, Ada itself is an inferior language.


Object-Oriented Software Construction
Bertrand Meyer
Prentice-Hall
- Ada is the subject of chapter 33 in the 2nd edition.  I haven't read the
2nd yet (the 1st was great). From what I've skimmed of it, he often makes
criticisms of C++, but fails to point out how the weaknesses in that
language have been corrected in Ada 95.

I often feel that, in spite of his obvious mastery of language theory, he
hasn't done a lot of Ada programming, and thus doesn't completely
understand the Ada way of thinking.  As Robert Dewar pointed out, you have
to spend a long time - years in fact - immersing yourself in a language to
really understand it.

My criticisms of certain Ada coding styles is based on this philosophy. 
Many Ada programmers - even ones doing it for a long time - don't really
"think" in the language.  You sometimes have to read between the lines of
the RM and Rationale to understand what the correct and intended usage of
the language is.

For example, a guy who really understands the Ada way of thinking is David
Emery.  He had a big hand in the writing of the POSIX 1003.5a (?) bindings,
which are far and away the best Ada bindings ever written.  A great example
of correct Ada 83 programming.  Everyone should read that standard, and
learn from it.

The SERC Ada X/Motif bindings, on the other hand, are truly pathetic.  It's
painfully obvious that the people who wrote those bindings had no idea what
they were doing.

I defended Bertrand on a thread about Design by Contract, but politely
disagreed with his assessment of Ada.  He sent me this funny note:

>Thank you very much for your comments. See my message
>on the newsgroups.
>
>By the way, I have great admiration for Ada 83 (although
>not for Ada 95).
>
>Best regards,
>
>-- BM

I had always thought he didn't like Ada 83; that's the impression I got
from reading the 1st ed of his book.  The 2nd edition discusses Jean's
falling out with the rest of the Ada 95 design team, and suggests his
leaving was because he felt the language was getting too complex.  (Others,
among them Robert Dewar and Bryce Bardin, have offered different
interpretations of the split.) 

Meyer seems to be trying to draw a parrallel between Ichbiah's leaving the
Ada 95 design, and the famous incident of Tony Hoare, Nik Wirth, and Edsger
Dijkstra leaving the Algol-68 design, because of their belief that
Algol-68's complexity was getting out of control.

In the end, you'll have to decide for yourself whether you think Ada is too
complex.

<mailto:bertrand@eiffel.com>
<mailto:ichbiah@twsolutions.com>


Some articles on the history of Ada are:

History of Programming Languages
Thomas Bergin and Richard Gibson, eds
Ada - The Project (in part V, Ada Session)
William Whitaker
- John Goodenough provides some insight into the design meetings with Jean
Ichbiah, saying how many votes went 10-to-1 and 12-to-1 against, with
Ichbiah's one vote having veto power over the rest of the design team.

I think that type derivation was one of the things everyone wanted to get
rid of, but Ichbiah fought for it and vetoed everyone else.  At least in
Ada 83, this is a language feature little understood and exploited by the
many Ada programmers I've met.  For this reason, I came to the conclusion
that this really would have been a good thing to not have included in the
language, and in fact Ledgard and Singer recommended subsetting it out. 
Even Wichmann put it under the "Changes that are possible but of
questionable value" category, saying that "There has been a lively debate
within the Ada community on this one."

Without type extension, I think derivation is of questionable usefulness. 
(One good use, though, is to effect the "transitivity of visibility"
technique, to gain direct visibility to a type and its operations.) 
However, Ada 95's designer, Tucker Taft, used this somewhat superfluous Ada
83 feature as the cornerstone of the object-oriented extensions to that
language.


Why Ada is Not Just Another Programming Language
Jean E. Sammet
CACM, Aug 86, Vol 29, No 8, p722-732
- Written by the author of the mother of all programming language books,
Programming Languages: History and Fundamentals

Abstraction Techniques in Modern Programming Languages
Mary Shaw
IEEE Software, Oct 84, p10-26
- discusses Ada's place in the evolution of abstraction features of languages



Proposals for Enhancement of the Ada Programming Language: A Software
Engineering Proposal
Mats Weber
- His PhD thesis. Discusses many of Ada's idiosyncrasies.

<mailto:mats.weber@lglsun.epfl.ch>


What Orientation Should Ada Objects Take?
J.P. Rosen
CACM, Nov 92, Vol 35, No 11, p71-76
-Jean-Pierre defends Ada's abstraction composition mechanisms.   I love
this paper!  It's one of the few that challenge the assumption that
inheritence is better than aggregation.

Jean-Pierre is a frequent contributor to comp.lang.ada.
<http://perso.wanadoo.fr/adalog/adalog2.htm>


Ada 9x: A Technical Summary
S. Tucker Taft
CACM, Nov 92, Vol 35, No 11, p77-81

Ada 9x: From Abstraction-Oriented to Object-Oriented
S. Tucker Taft
OOPSLA 93 proceedings, p127-135
- a pair of articles from Ada 95's lead designer

<mailto:stt@inmet.com>


I've been thinking of writing a book about Ada's history, and have been
collecting articles like this.  I'd like to write a book that explains how
to think in Ada, and explicates Ada programming philosophy.  There's some
of this sort of thing in Norm's book, but I'd like to have a (shorter) book
that condenses the essential concepts.

Feel free to write or call if you have any questions.