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: 107079,eca28648989efca9 X-Google-Attributes: gid107079,public X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public From: Alan Brain Subject: Re: Ariane 5 failure Date: 1996/09/29 Message-ID: <324F0E96.ADD@dynamite.com.au>#1/1 X-Deja-AN: 185989892 references: <1780E8471.KUNNE@frcpn11.in2p3.fr> <1996Sep27.023246.18774@jarvis.cs.toronto.edu> content-type: text/plain; charset=us-ascii organization: @Home mime-version: 1.0 reply-to: aebrain@dynamite.com.au newsgroups: comp.lang.ada,sci.math.num-analysis x-mailer: Mozilla 3.0 (Win16; I) Date: 1996-09-29T00:00:00+00:00 List-Id: Richard Pattis wrote: > > As an instructor in CS1/CS2, this discussion interests me. I try to talk about > designing robust, reusable code.... --->8---- > The Ariane falure adds a new view to robustness, having to do with future > use of code, and mathematical proof vs "engineering" considerations.. > > Should a software engineer remove safety checks if he/she can prove - based on > physical limitations, like a rocket not exceeding a certain speed - that they > are unnecessary. Or, knowing that his/her code will be reused (in an unknown > context, by someone who is not so skilled, and will probably not think to > redo the proof) should such checks not be optimized out? What rule of thumb > should be used to decide (e.g., what if the proof assumes the rocket speed > will not exceed that of light)? Since software operates in the real world (not > the world of mathematics) should mathematical proofs about code always yield > to engineering rules of thumb to expect the unexpected. > What is the rule of thumb about when should mathematics be believed? > Firstly, I wish more there were more CS teachers like you. These are excellent Engineering questions. Secondly, answers: I tend towards the philosophy of "Leave every check in". In 12+ years of Ada programming, I've never seen Pragma Suppress All Checks make the difference between success and failure. At best it gives a 5% improvement. This means in order to debug the code quickly, it's useful to have such checks, even when not strictly neccessary. For re-use, you then often have the Ariane problem. That is, the un-neccessary checks you included coming around and biting you, as the assumptions you were making in the previous project become invalid. So.... You make sure the assumptions/consequences get put into a seperate package. A system-specific package, that will be changed when re-used. Which means that if the subsystem gets re-used a lot, the system specific stuff will eventually be re-written so as to allow for re-use easily. Example: Car's Cruise Control: MAX_SPEED : constant 200.0*MPH; Get's re-used in an airliner - change to 700.0*MPH. Then onto an SST - 2000.0*MPH. Eventually, you make it 2.98E26*MetresPerSec. Then some Bunt invents a Warp Drive, and you're wrong again. Summary: Label the constraints and assumptions, stick them as comments in the code and design notes, put them in a seperate package...and some dill will still stuff up, but that's the best you can do. And in the meantime, you allow the possibility of finding a number of errors early. ---------------------- <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM ---------------------- o OO*O^^^^O*OO o oo oo oo oo By pulling Maerklin Wagons, in 1/220 Scale