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: 103376,e80a1497a689d8a5 X-Google-Attributes: gid103376,public From: "Robert I. Eachus" Subject: Re: Ada GC (was Re: Ammo-zilla) Date: 1999/11/12 Message-ID: <382C6E50.E43639E2@mitre.org>#1/1 X-Deja-AN: 547866029 Content-Transfer-Encoding: 7bit References: <38120FAF.945ADD7D@hso.link.com><7uutgd$87h$1@nnrp1.deja.com> <19991024.18033546@db3.max5.com><38189268.43EB150F@mail.earthlink.net><86ogdjtdwz.fsf@ppp-115-70.villette.club-internet.fr><7vadsp$8q61@news.cis.okstate.edu> <1999Oct28.221910.1@eisner><7vb3c4$8a21@news.cis.okstate.edu> <7vhg2n$7ht$1@nnrp1.deja.com> <7vkjea$b34$1@nnrp1.deja.com> <7vncgr$bpg$1@nnrp1.deja.com> <7vqd45$iiq$1@nnrp1.deja.com> <7vvroo$grr$1@nnrp1.deja.com> <80c9fq$2qn$1@nntp4.atl.mindspring.net> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.mitre.org X-Trace: top.mitre.org 942435562 4195 129.83.41.77 (12 Nov 1999 19:39:22 GMT) Organization: The MITRE Corporation Mime-Version: 1.0 NNTP-Posting-Date: 12 Nov 1999 19:39:22 GMT Newsgroups: comp.lang.ada Date: 1999-11-12T19:39:22+00:00 List-Id: Richard D Riehle wrote: > What we call a "bug" is actually a mistake. Someone tried to do something > and made a mistake. The mistake results in a defect. The defect is a > potential run-time fault. Managers need to take the responsibility for > elminating the word "bug" from the vocabulary of their software personnel. I have to disagree. Yes, most bugs are mistakes, and are determineded to be design errors or implementation errors. However, there are other categories of bug that do not involve mistakes. For example, ACT considers misleading error messages from the compiler to be bugs. I agree, but since the "right" error messages can only be determined by experience, these bugs are usually not mistakes. As another example, failure to follow coding standards can be mistakes. But if the standard changes, or more likely code developed with one standard is merged with code using a different standard, the discrepancies are bugs. (Not fixing them is a mistake, but at first they are bugs.) Similarly, if you are moving code forward to use a new version of some COTS product, incompatibilies are bugs, but they are normally not mistakes. These conditions are not limited to software. For example, if your job is to modify a transmission design to work with a different engine, there may be many discrepancies to be resolved. These were not originally mistakes, and they will only be potential faults if you fail to resolve them. Or consider circut board layout. If your original try at laying out a board has 73 disconnects, it doesn't mean that you made 73 mistakes. It may take you days to reduce that number to zero (or in some cases to a small number of wires), but that is part of the design process. Some people would go further and say that all potential faults detected during unit test, or even integration test are not mistakes. I don't feel that all fall into that category, but there are certainly cases where the job of integration is to resolve unintended conflicts where there is no blame to be allocated. Of course, one of the nice things about Ada is that there are very few opportunities to innocently create such conflicts. On the other hand using a C++ compiler without namespace support is a mistake, and the blame should be laid somewhere if you get to integration and you have unrepairable naming conflicts. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...