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,e01bd86884246855 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: "David K Allen" Subject: Re: Interresting thread in comp.lang.eiffel Date: 2000/07/12 Message-ID: #1/1 X-Deja-AN: 645751857 References: <8ipvnj$inc$1@wanadoo.fr> <8j67p8$afd$1@nnrp1.deja.com> <395886DA.CCE008D2@deepthought.com.au> <3958B07B.18A5BB8C@acm.com> <395A0ECA.940560D1@acm.com> <8jd4bb$na7$1@toralf.uib.no> <8jfabb$1d8$1@nnrp1.deja.com> <8jhq0m$30u5$1@toralf.uib.no> <8jt4j7$19hpk$1@ID-9852.news.cis.dfn.de> <3963CDDE.3E8FB644@earthlink.net> <3963DEBF.79C40BF1@eiffel.com> <2LS85.6100$7%3.493920@news.flash.net> <8k5aru$1odtq$1@ID-9852.news.cis.dfn.de> <8k8pk2$20cab$1@ID-9852.news.cis.dfn.de> <_dS95.9945$7%3.666180@news.flash.net> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Complaints-To: abuse@visi.com X-Trace: ptah.visi.com 963459553 209.98.239.164 (Wed, 12 Jul 2000 22:39:13 CDT) X-MSMail-Priority: Normal NNTP-Posting-Date: Wed, 12 Jul 2000 22:39:13 CDT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-12T00:00:00+00:00 List-Id: "Ken Garlington" wrote > It keeps getting ignored (I suspect because the question can't be answered), > but I'll post this example again. The DbC specification for a module is > given below. I feel fairly confident that this is considered a good quality > example by at least one acknowledged Eiffel/DbC expert. ;) > > convert (horizontal_bias: INTEGER): INTEGER is > require > horizontal_bias <= Maximum_bias > > If, as you say, this would cause the project team to go get information they > did not already have, then explain what information it would require and > why. > > (My analysis of this DbC specification is in the link noted above). First, I don't think the authors intended that this one function would have prevented the entire disaster. If they meant that, then I must join you in your critique. I think they were trying to give an illustration that would convey the approach of DBC in the context of the disaster. But I can see you were not impressed . Second, as you point out in your critique, the error occurred prior to where this function would have been used (conversion from FP to Integer). But if you accept my previous remark, then that is not the point of their example. I admit they chose poorly if they were intending to persuade you, who have such a command of the details. But for conversation sake, and to illustrate the usefullness of DBC, let's assume that the flaw occured within 'convert' above. Otherwise, I can't help you see how DBC helps me think and work. When I am writing a routine that uses a function (like 'convert'), and I see a precondition (like hb <= Mb), I say to myself: "As the client (user) of the routine, I better be prepared to honor its preconditions or I risk failure." So I take either of two approaches in such a case. I either choose to test the precondition myself, before calling 'convert', or I choose to ignore it, and assume that an error MAY occur in the precondition, and I prepare to trap the exception that may result and handle the failure. That is a style point for systems where reliability is important. But this seeems equivalent in my mind to "protecting the variables." And the inquiry noted (your footnote (6)) "It is important to note that the decision to protect certain variables but not others was taken jointly by project partners at several contractual levels" Yes, I know - the reason for this jointly agreed decision was cited as maintaining CPU performance. My only claim is that if DBC were part of the coding culture, it would have been less likely that that decision would have been "jointly" agreed to. If I were working on high-risk stuff with a team of others trained in DBC, I can't see that we would reach a consensus to ignore the warning of a precondition. It just would not be done without management overriding us. Without the DBC guidelines or something equally simple and easy to understand, I fear that such decisions simply degenerate into very fuzzy gut-level (is it good enough) decisions. Although all devleopment ultimately has that anyway. I really believe that DBC might have tipped the balance. Most importantly, in the practical world in which we work and live, I consider DBC to be easy to understand and powerful at the same time. Perhaps the language of the original authors you criticize was too bold or propgandistic for your taste. But I'm glad it struck you that way. I learned more about why I like DBC by reading your criticisms;) As I read the inquiry, it strikes me how a team that practices DBC routinely would have probably made different choices. But I agree that there were a host of other issues, and DBC alone would not rescue things. -- Best Wishes, David Kreth Allen Software Consultant Minneapolis, Minnesota - USA