From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 1 Sep 93 21:08:56 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!olivea!news.bu.edu!inm et!spock!stt@ucbvax.Berkeley.EDU (Tucker Taft) Subject: Re: Hoare's gripes about Ada (was Re: Ada and C++ ...) Message-ID: List-Id: In article 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