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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: Ted Velkoff Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/08/13 Message-ID: <33F133D7.71AC@erols.com>#1/1 X-Deja-AN: 263859993 References: <33E9ADE9.4709@flash.net> Organization: Erol's Internet Services X-Received-On: 13 Aug 1997 04:07:57 GMT Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-13T00:00:00+00:00 List-Id: Jon S Anthony wrote: > > The problem with this is the simple observation of "why would the > assertions be there in the first place?" After all, in the particular > case at hand, they were _intentionally_ removed. And with perfectly > sound engineering principles in mind. Assertions in the code _cannot_ > capture the constraints presumed for the context of use. This has to > come from somewhere else (external documentation, "instructions", > "warrenty notes", whatever.) [...] > There is an important distinction between including/removing assertions and monitoring/not monitoring them during execution. One of the principal benefits of Eiffel is the fact that assertions remain in the code (where programmers will see them) even if they are not tested dynamically (this is controlled by a compile-time switch). Whether or not this would have saved Ariane V, the documentation and testing benefits of Eiffel's assertions would benefit many, many software projects. -- Ted Velkoff