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: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: OO, C++, and something much better! Date: 1997/01/27 Message-ID: #1/1 X-Deja-AN: 212545338 references: <5buodl$bci@boursy.news.erols.com> <32E2FEC7.2F7B@concentric.net> <5bvncj$gqg$1@A-abe.resnet.ucsb.edu> <32E47B4B.56D9@concentric.net> <6PI998tV3RB@herold.franken.de> <32E68D40.65EC@parcplace.com> <32E999AE.2F68@parcplace.com> <01bc0c4d$8a0108f0$c318b993@jarvisb> organization: New York University newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.lang.eiffel Date: 1997-01-27T00:00:00+00:00 List-Id: Bob says "And, pray tell, what do *you* rely on to ensure reliability? Purity of thought and the best of intentions? :-) I don't care what language a particular piece of software is written in. If it' s *my* project I'm going to ensure it's tested thoroughly before it's deployed. Robert replies The tone of this reply certainly is a typical hacker's attitude that it is impossible to write correct code, and that the only possible approach is to write incorrect code, and then hope to correct it by testing. In fact it is essentially impossible to write really high reliability software this way, e.g. safety critical software. Sure testing plays a role, especially disciplined testing such as code and path coverage testing, but it is inconceivable to rely on testing alone. Writing correct code has nothing to do with purity of thought or good intentions. It has to do with using a disciplined approach, aided by formal specification and formal reasoning, often with the use of tools specifically designed to support this approach (e.g. the PRAXIS Examiner). Actually I would prefer to use the word rigorous to formal in the above paragraph, because formal to many people means mathematically formal, and although mathematical formalisms are important tools, they are not the only possible approach. Testing can reveal the presence of bugs sure, but haphazard testing cannot provide the absence of bugs. It is true that formal testing techniques are a legitimate part of a formal approach, and can be used to verify or provide theorems and invariants about the code, but only if the code has been developed in a rigorous manner to start with. On the other hand, it is quite possible to generate high reliability code with no testing whatsoever. For more information on this possibility (which often seems almost incredible to the test-debug crowd), read up on the cleanroom approach to generating software, an approach in which the development team is not permitted to do any testing!