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,a83c46b54bacb7f6 X-Google-Attributes: gid103376,public From: "Mike Silva" Subject: Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co Date: 2000/02/01 Message-ID: #1/1 X-Deja-AN: 580395388 References: <3894A823.92EC75D1@bondtechnologies.com> <874b7r$mj9$1@nnrp1.deja.com> <38967537_1@news.jps.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Complaints-To: news@wenet.net X-Trace: news.wenet.net 949423225 206.169.137.33 (Tue, 01 Feb 2000 08:40:25 PST) X-Received-Date: Tue, 01 Feb 2000 08:40:42 PST (newsfeed.avtel.net) NNTP-Posting-Date: Tue, 01 Feb 2000 08:40:25 PST Newsgroups: comp.lang.ada Date: 2000-02-01T00:00:00+00:00 List-Id: Hyman Rosen wrote in message ... >"Mike Silva" writes: >> This is a silly strawman, since nobody (at least, nobody who wants to be >> taken seriously) ever makes such extreme claims. It's all a matter of >> increasing the odds, and both the C language and the C culture invite buggy >> code (sad to say, I've written my share). Every C programmer should perform >> the eye-opening exercise of determining how many C bugs they encounter would >> not have been possible, or would have been quickly spotted, in Ada. > >I would assume that for safety-critical code, the development process >is such that these errors would be found if they were present. After >all, Ada's error checks can help only in the development process, not >once the pacemaker is installed, so the code would have to be carefully >checked to make sure that no exceptions would actually be triggered. >This is the same process the C code would go through. Firstly, shortening the development process by catching more errors quicker is a Good Thing. Secondly, I can imagine plenty of scenarios where software and/or hardware glitches can be captured, corrected in some manner (even if via restart) and logged in a running pacemaker, to be analysed later, perhaps resulting in the loading of improved code into the device (I believe this is possible -- it certainly should be!), or leading to hardware improvements. Surely a pacemaker has to be able to recover quickly from just about any data foul-up possible, and no amount of design and testing can provide a 100% guarantee against such foul-ups. The essence of your comments seems to be that equal cost and quality code can be produced with any language. This seems like an ivory tower position, ignoring the constraints of time, money and human fallibility. Mike