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: fac41,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/24 Message-ID: X-Deja-AN: 228030549 Distribution: world References: <332B5495.167EB0E7@eiffel.com> Organization: PSI Public Usenet Link Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.lang.ada Date: 1997-03-24T00:00:00+00:00 List-Id: In article <33343EE3.7DE14518@eiffel.com> Bertrand Meyer writes: > Is it ever possible to have a technical discussion without > resorting to insults? Jon S. Anthony finds it productive to write, > about one of my earlier messages: Yes, it is possible, and I admit that you indeed did successfully goad me into making these comments. The frustrating part is that you just simply deny some facts - over and over. I'm not sure why you want to deny them - it's not as if they make that much of a difference to your overall case. That is what goaded me into these statements. Also, I have no problem whatsoever with your being biased toward Eiffel here. Both for technical reasons as well as business reasons. I just don't understand why you should bother trying to deny it or pretend that the paper in question is not rather blatently biased against any other implementation language. What's the point? It's not as if anyone actually believes these denials and they don't make any difference to your position anyway (unless you are trying to assume some air of objectivity in the matter??) > It is this type of gratuitous attack that empoverishes Usenet and has > the potential to destroy it. When people who know what they are talking > about, and could contribute usefully to the debate, see this kind of > absurdity, they refrain from participating. Everyone loses. Indeed you are correct and I apologize here and now for doing the very sort of thing that I have decried myself. Ugh! I am dooly (sp?) embarassed. > I assume Mr. Anthony's hope is that by making sufficiently outrageous > statements he'll win by causing others either to lose their temper No, on the contrary - it was you who successfully made me lose my temper... > > Ada _has_ assertions. Their form is not of the same syntactical look > > as Eiffel's. So what? They take the form of constraints, in > > particular (wrt to the case at hand) subtype constraints > > OK. Ada has assertions. Great news! I have read a lot about Ada but > must have missed them. So let's see what their application would be > to a typical example of Design by Contract. Why not take the case in hand? The Ariane one? Perhaps because that case is easily handled by Ada constraints? Oh, by the way, you left out the part where I clearly concede they are not as capable or general as Eiffel's: "They are _not_ as flexible or full "featured" as Eiffel's but they are certainly there and in the Ariane case" Any particular reason why you would want to do that? > Take a class PERSON in a system for genealogical or demographical > analysis. Here are some of the logical properties to be documented > and enforced: Hmmm, Clearly you are being nicely sarcastic here, but I never said that Ada's "assertions" were as flexible and as widely capable as Eiffel's. So, this is a strawman and simply irrelevant. > Now if Ada has assertions, how would you express the above properties? Come on, who ever claimed that Ada's constraints are anywhere near as capable as Eiffel assertions?? Quote anything anywhere of mine where I even hinted at such a ridiculous claim. In fact, I have often stated (even in the message that started this) that they are much more capable and that I think Ada95 goofed in not putting in some better support for them. BUT. "Not as capable" does not mean does not exist. A simple matter that I am sure you would agree with. In fact, "not as capable" clearly implies they exist - lest there would not be anything to not be as capable. So, this entire example, is nice and quite good, but has nothing to do with the topic or the point. Ada does have assertions and in the particular case at hand, the Eiffel you gave in your paper has an _exact_ analogue in Ada. I've stated it a couple three times. No point in repeating it again. > `assert not other.married'. Instead, we are interested in > associating with every software element - class or routine - > a precise specification, or "contract", describing > its obligations and benefits. The contract will serve as > help in the analysis-design-implementation process (as briefly > mentioned above), as documentation of the final software, as > aid in debugging - by turning on run-time assertion monitoring > in Eiffel environments -, as safeguard in using inheritance, as > a basis for exception handling etc.) All of this is great and wonderful and I wish you had put the case more like this in both your paper and in your subsequent comments on news. Perhaps the mistake was in using trying to use an inappropriate example (Ariane failure) as somehow being a case where Eiffel assertions would have saved they day when the evidence clearly suggests they wouldn't have. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com