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,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: The stupidity of all the Ariane 5 analysts. Date: 1997/07/21 Message-ID: #1/1 X-Deja-AN: 257988699 References: <33C835A5.362A@flash.net> <33CC0548.4099@flash.net> <5qitoi$fdv$1@news.irisa.fr> <33CD6512.2404@flash.net> <01bc92e6$7a6f9e40$287b7b7a@tlo2> <33CEAF05.6389@flash.net> <33D2827B.41C67EA6@eiffel.com> <5qucs7$jie$3@flood.weeg.uiowa.edu> Organization: New York University Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-21T00:00:00+00:00 List-Id: Bertrand said <<>All this is rhetorics and cannot succeed to obscure the basic >claim that systematic use of Design by Contract would probably >have avoided the crash. >> Well all sorts of things would have avoided the crash. One can also say that systematic proof of correctness, or systematic code review, or in fact almost any steps to be a bit more careful in this particular area, would have avoided the crash. As usual, a disaster of this type is a chain of occurrences, and fixing any one of them would have avoided the problem. Certainly the notion of clear interfaces and interface requirements (I find the use of the capitalized "Design by Contract" a little pretentious, since I see no new concept there that justifies a new technical term) is one which we can all agree on. The argument that the use of Eiffel would have prevented the problem is entirely unconvincing, and has the unfortunate effect of encouraging people to think that the entire argument is just empty language advocacy. When there is a major screwup in software (some examples, the long lines failure at AT&T, the Denver baggage handling, the overnight funds transfer disaster in an NY bank etc), there is a natural tendency for over enthusiastic pushers of a particular language to try to argue that their particular pet language would have guaranteed freedom from the problem. Such arguments are never convincing, because even if it *were* the case that the particular problem at hand might *possibly* have had a better chance of being avoided writing in language X, extending this to the allegation that the use of language X would in general have been beneficial stretches credibility. In particular, in a large complex system of this type, the language and all other components have to meet all kinds of complex requirements, and people who know nothing at all about the whole application have no idea whatsoever if their pet language would in fact meet the criteria. If Bertrand is saying: (a) The Ariane problem (at least little piece of it) is a good example of why designing interfaces that are complete with respect to establishing a requirements contract for clients is a good idea. (b) One of the attractive features of Eiffel is that it supports this concept directly and encourages programmers to use this approach. Then the argument is entirely reasonable, and one that I cannot see anyone objecting to. But the way the argument is stated, it reads as though he is saying: If Eiffel had been used for the Ariane project, it would not have crashed. And I find that claim entirely unjustified, and it detracts from the important underlying point. No language can force people to do things right, and to a large extent no language prevents people from doing things right. What a language can do is to encoruage a style of programming and thinking that helps people find their way to doing things right a little more easily. This is indeed the principle behind the Ada design, and a lot of the reason that Ada is successful in practice is precisely because it encourages "good thinking". But when people said "if only the Denver baggae system had been written in Ada, I would be flying to the new airport today", this crossed the line into non-credible language advocacy. Similarly, a lot of the thinking behind the Eiffel design is also to encourage "good thinking", and in that sense Ada and Eiffel are kindred spirits in their approach to language design, though they make different choices about what is important to encourage. However, when the Eiffel advocacy crosses the line to saying that a large complex system, if written in Eiffel, would have succeeeded where otherwise it failed, again this crosses the line into non-credible language advocacy. I am, as everyone knows, a strong advocate of the use of Ada. However, I take a lot of care NOT to make exaggerated claims, since I don't think this helps at all. What Ada (or any other language) can do, is to push programmers up a little bit on the quality and productivity scales. A little bit may not sound like much, but these scales are logarithmic scales in which the productivity of programmers and the quality of the code they right varies over orders of magnitudes, so a "little bit" can add up to very substantial savings in costs, and very substantial improvements in quality in practice.