From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,52fd60a337c05842 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-15 11:01:34 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.mathworks.com!wn3feed!wn2feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc53.POSTED!not-for-mail Message-ID: <3D0B813A.3040204@attbi.com> From: "Robert I. Eachus" Organization: Eachus Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.61.239.24 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc53 1024164093 24.61.239.24 (Sat, 15 Jun 2002 18:01:33 GMT) NNTP-Posting-Date: Sat, 15 Jun 2002 18:01:33 GMT Date: Sat, 15 Jun 2002 18:01:33 GMT Xref: archiver1.google.com comp.lang.ada:26033 Date: 2002-06-15T18:01:33+00:00 List-Id: Lyle McKennot wrote: > How about the 1980 ACM Turing Award lecture "The Emperor's Old > Clothes" ? > > After all, it was that scathing attack by Hoare that made a lot of > people in the academic community abandon Ada. > > It is still available at : > > http://lambda.cs.yale.edu/cs422/doc/hoare.pdf Have you even read (or heard) this speech, and if you have, have you tried to relate it to the current version of Ada? If you had, you would realize that Tony's criticisms of Ada 80 were valid, most did not apply to Ada 83, and no one in their right mind would consider his remarks about Ada 80 to apply to Ada 95. In fact you can probably recognize that Tony's arguments in certain areas prevailed. Some features of Ada 83 that were not important to all classes of users were moved to optional annexes, other annexes were added to deal with programming domains not considered in the design of Ada 80 or Ada 83. In one sense Tony lost on exceptions. But as the long discussion on exception arguments here have shown, Ada provides the necessary functionality to everyone, and provides some extensions to those who want to do more with them. But in general, almost every Ada programmer agrees that exceptions are to be avoided. Not as a language feature, but as evidence of a bad program. Any program that raises Program_Error is badly broken, other than, of course, a compiler test that validates that Program_Error is raised and handled appropriately. With modern computers, the only time anyone ever sees Storage_Error is when a newbie writes: "Foo: String;" Pretty soon even that won't be guaranteed to raise an exception, but I hope compilers will still provide warning messages. ;-) Ada 80 had some serious problems. For one thing it had too many predefined exceptions. Most of these were gone from the Ada 83 standard, but we still missed one (Numeric_Error). That problem was actually fixed before the design of Ada 95 was started. Another major problem was the order of elaboration rules. I wrote a cute program which was a legal Ada 80 program if, and only if, Fermat's Last Theorem was true. Ada 95 (and Ada 83) compilers are allowed to generate code that would raise Program_Error if FLT was false, and otherwise spent a very long time initializing. (Or you could turn off Elaboration_Check.) Of course, if someone wants to, they can build a special check into their Ada 95 compiler which optimizes away the dependence on FLT. The last is not humor, it is serious. The change in the definition of what it means to execute an Ada program between Ada 83 and Ada 95 is very subtle, but important. And Ada 95 compiler is allowed greater freedom in optimizing away truly useless code, and slightly less freedom to optimize away checks that have a real effect on the result of the program. Is getting exceptions right very tough? Yes. But the right way to deal with that is in the langauge definition so that ordinary programmers can produce code that works without having to think about exceptions all the time. (But you have to think about them during requirements analysis and the design process. The Arianne 4 team did this right, the Arianne 5 project did not redo the requirements analysis...)