Re: Hoare's gripes about Ada (was Re: Ada and C++ ...)

[dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!olivea!news.bu.edu!inm et!spock!stt@ucbvax.Berkeley.EDU (Tucker Taft)]

In article <nbhCCnzpL.1D8@netcom.com> nbh@netcom.com (N.B. Hedd) writes:

>Ted, Ted, Ted--before using Hoare as an authority on language design, can
>you please enumerate for me the languages that Hoare himself has designed
>that have proven to be commercial successes? 'Cause personally I can't
>think of anything significant he's done in the field of language design.

> ... [other similar silly statements about Hoare deleted]

This is the strangest post I have ever seen.  Hoare was the inspiration
for Pascal, which in turn provided inspiration for Ada, Eiffel, Modula,
etc.  Of course I rarely find myself in agreement with Ted Holden's posts,
but I certainly agree with him that Hoare is one of the greats
(perhaps the greatest) in the history of programming language design.

You should read Structured Programming (Dahl, Dijkstra, and Hoare -- AP 1972),
and any history of programming languages.

In any case, the issue is not whether Hoare thought Ada was too complex
in 1980 (perhaps it was "ahead of its time" in sophistication, having
tasking, generics, exceptions, packages, overloading, user-defined 
operators, etc.).  Clearly Ada 83 is not ahead of its time in 
sophistication/complexity anymore, when compared with Fortran 90,
C++ 3.0/4.0, Cobol 9X, etc.  The programming problems have gotten 
more complex, and the mainstream systems programming community 
has generally embraced the idea of adding more features 
to the language if by so doing it significantly simplifies 
the construction of correct, robust, maintainable, and extensible programs.

A while back there was a bit of a debate about small "academic"
languages versus large "commercial" languages.  This really has
nothing to do with academia versus industry.  As was pointed out,
many very large, long-lived systems have been built in academia (e.g.
Mach, Ingress, Andrew File System, PQCC, etc.).  However, these were
not generally written in what are traditionally called "academic" languages.
Instead they were written in C, Bliss, etc. -- traditional (low-level) 
systems programming languages.  In fact, it was experience in academia
and industry with such large, long-lived systems that created much of
the impetus for adding object-oriented features to systems programming
languages.

There is still an important academic contingent interested in "small"
languages, partly out of the general principle that "simpler is better
if it works" (which I certainly agree with), and perhaps more importantly
out of an interest in languages that are conducive to formal semantic
analysis.  Of course, the great challenge for this academic
contingent interested in formal semantic analysis is either to:

 a) convince the builders of large, long-lived, "real-world" systems that 
    these "small" languages are sufficiently expressive and productive 
    to allow their use on big systems; or to

 b) generalize the principles learned in analyzing small languages
    and apply them to the large, "real world," "messy" languages being
    used by the mainstream.

Personally I see the current academic efforts focused on small languages as
being analogous to the kinds of small, isolated experiments that are performed
during the early period of any area of scientific study.  I hope
that once these small languages are well understood, the fundamental
principles learned will be able to be generalized to handle the
languages of the "masses."

On the other hand, I know many of the researchers in these areas believe
their small languages are already sufficiently expressive and productive,
and because of their formal semantic foundation should be adopted by
all programmers seriously interested in building robust, reliable systems.

This difference of opinion will probably continue for quite some
time, during which the "well founded" languages will probably grow
more sophisticated and less restrictive (e.g. SML), and 
the "mainstream" languages will probably
acquire more complete and well founded definitions.  Certainly
for Ada 9X, in developing the "Integrated Language Specification"
document, we tried to be as formal as possible, while remaining
in English.  We have carried most of the formality over to the actual 
Reference Manual, though some of the most pedantic material has been relegated
to the "Annotated" Ada 9X Reference Manual, available for perusal
by formal language theorists, language lawyers, compiler implementors,
and other readers interested in maximum precision at the occasional
expense of easy readability.

S. Tucker Taft    stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138