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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,f66d11aeda114c52 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,f66d11aeda114c52 X-Google-Attributes: gid103376,public From: Bertrand Meyer Subject: Re: Critique of Ariane 5 paper (finally!) Date: 1997/08/13 Message-ID: <33F22B91.167EB0E7@eiffel.com>#1/1 X-Deja-AN: 264023639 References: <33E503B3.3278@flash.net> <33E8FC54.41C67EA6@eiffel.com> <33E9B217.39DA@flash.net> <33EA5592.5855@flash.net> <33EB4935.167EB0E7@eiffel.com> <33EB754E.446B9B3D@eiffel.com> <33EBE46D.2149@flash.net> <33EF9487.41C67EA6@eiffel.com> Organization: Interactive Software Engineering Inc. Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-08-13T00:00:00+00:00 List-Id: Professor Robert Dewar wrote that my argument > seems over-facile and rather academic Wow! But I'll choose to take "academic", coming from a .edu address, as a compliment. And "over-facile" might refer to how easy the basic ideas of Design by Contract are to teach and implement. He adds that what he calls my "jump from sufficient to necessary" > can only be regarded as advertising puffery. Advertising puffery! Delightful choice of words. Now this is a solid technical rebuttal. But here is the explanation: > [I]t is clear that you [i.e. me, BM] are not disinterested > in the claim! OK, finally things are clear. When everything else fails, resort to questioning the other person's integrity: I have a vested interest in seeing Eiffel succeed -- that explains it all. (Doesn't explain, though, why so many other contributors have expressed agreement with the analysis of the Jezequel-Meyer Ariane paper and support for Design by Contract.) This is a slippery path to follow since very few people can claim to be "disinterested". So are Robert Dewar and I going to spend the next three months arguing who is the most unbiased? No, no and no. I won't be dragged down to that level and will just assume that the line quoted above was a regrettable slip of the pen. The "necessary" condition is simple: you won't get reliable software unless you take care to associate specifications -- contracts -- with software elements, especially reusable components. You can then use these contracts to build the software, to document it, to validate it statically, to test it (if you have support for run-time monitoring, as in Eiffel), to control the proper use of inheritance, to discuss the software within the software team as well as with management, customers, users and regulatory agencies. Anyone who has used the approach knows that it dramatically improves the quality of the product and the process. And it's not even an expensive technique. No one ever said Design by Contract was "sufficient". My "Object-Oriented Software Construction, 2nd Edition" (Prentice Hall) has a 9-page section (11.14, pp. 398-406) discussing its limitations. But to encourage developers of mission-critical software to ignore this powerful tool is irresponsible. How many more Ariane-like failures do we need? -- Bertrand Meyer, President, ISE Inc., Santa Barbara (California) 805-685-1006, fax 805-685-6869, Web: http://www.eiffel.com, with instructions for free download == ISE Eiffel 4: Eiffel straight from those who invented it ==