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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: Ken Garlington Subject: Re: Critique of Ariane 5 paper (finally!) Date: 1997/08/13 Message-ID: <33F25869.55E3@flash.net>#1/1 X-Deja-AN: 264038678 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> <33F22B91.167EB0E7@eiffel.com> Organization: Flashnet Communications, http://www.flash.net Reply-To: Ken.Garlington@computer.org Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-08-13T00:00:00+00:00 List-Id: Bertrand Meyer wrote: > > (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.) How many of them build safety-critical real-time systems? None who support DBC have indicated experience in this field. Thus, my explanation is simple: they have insufficient experience to judge the likely pitfalls in the application of DBC to a domain they (and, I assume, you) don't understand. Your case seems to be somewhat less strong among the actual practitioners in the field. Coupled with the apparent lack of Eiffel applications in the domain under discussion, your appeals to authority (random Eiffel users on Internet?) aren't all that compelling. > 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. On the other hand, _I_ have absolutely no vested interest in either promoting Ada or attacking Eiffel; nor do I have any interest in defending the Ariane 5 team. I do have an interest in using new technologies in the domain in which you have taken a sudden interest, and would like to understand how it could help. However, my concerns have been uniformly unaddressed through any sort of technical argument. I notice that both you and Mr. Jezequel have a strong desire to uncover "vested interests." When I first joined this discussion, he assured me that my job as a software test engineer would not be eliminated by a switch to DBC. Since I'm not a software test specialist, this was a strange statement to make, to be sure. :) So, other than some perceived bias of practitioners against "the next big technology." as I believe you indicated in a previous post, what is the bias that practitioners such as myself, Mr. Kohl, and Mr. White have against DBC (other than the obvious one -- we won't use a technology whose authors are so emotionally involved in their quest that they are insulted by the mere suggestion of contrary views)? > 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". Other than youself, in your Ariane 5 paper. Perhaps it's a problem of the English language; but "probably yes" certainly translates as "sufficient" in my understanding. > 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. This is really the true irony. Several practitioners have invested a great deal of Internet time _not_ ignoring this technology. We have tried to understand why it would help in our domain; have tried to draw the Eiffel experts into a technical discussion of its strengths and weaknesses, and have generally been told -- we don't understand our own products -- we don't understand software engineering -- we are biases against new ideas I wonder why there aren't more Eiffel projects in this domain? :) Mr. Jezequel and Mr. Meyer have both indicated they have no interest in pursuing any discussions on this subject. Isn't this the same as irresponsibly discouraging the use of DBC? >How many more Ariane-like failures do we > need? No more. This is why we need a balanced budget immediately! (Why not? If I don't have to show that a balanced budget would have prevented the problem, it's an equally important claim!) > > -- > 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 ==