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: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: Dave Wood Subject: Re: Is there a language that Dijkstra liked? (was: Re: Software landmines (loops)) Date: 1998/10/27 Message-ID: <3636952F.1FA6206B@cts.com>#1/1 X-Deja-AN: 405804196 Cache-Post-Path: wagasa.cts.com!unknown@arniek.cts.com Content-Transfer-Encoding: 7bit References: <712i5t$9i$1@nnrp1.dejanews.com> Content-Type: text/plain; charset=us-ascii Organization: Deja Vous Productions Mime-Version: 1.0 Reply-To: dpw@cts.com Newsgroups: comp.lang.eiffel,comp.software-eng,comp.lang.ada Date: 1998-10-27T00:00:00+00:00 List-Id: dennison@telepath.com wrote: > > The part that I find tres' cool is that the run-time checks tend to make a > buggy program bomb very close to the true source of the problem. Without it, > bugs surface randomly. On a large networked system It can take weeks just to > find the source of such a "random" bug. Wow, if this doesn't hit close to home! I just spent many agonizing days tracking down such a problem in a voice mail system I developed in C. Even using every compiler check and a third-party bounds-checking tool (Memcheck), I was still unable to detect the source of the problem (although I did find another array overrun problem that did not have an immediate negative effect - this particular problem would have been found at compile time in Ada.) The problem *only* manifested itself when the system was installed in the telco CO while it was processing 100,000+ calls a day, and even then it happened at an unpredictable time approximately once a day, causing a total system crash. Telephone companies aren't real happy with an MTBF of 24 hours! It's very hard to take the system off-line or produce diagnostics without making it unusable by the end-customers or making it impossible to create the proper malfunction conditions. This is like the physics Uncertainty Principle: examining the problem changes the conditions sufficiently such that the problem can't be found! In the end, we found the problem by sheer blind luck - when an OS parameter was changed to accidentally low value, we noted that the same kind of crash occurred at a higher frequency. The smoking gun! I grant you, with exceptionally good and clean engineering, this should not happen, even in C. But the world is positively exploding with lousy programmers (like me, although in this case the bug was introduced by someone else, which no doubt made it that much harder for me to find.) Had a decent Ada development environment existed for the PC platform back when this project started (1989) I never would have used C in the first place. On the bright side, I guess you could say it gave me a mission in life - to help bring such an environment to market. -- Dave Wood, Aonix -- Product Manager, ObjectAda for Windows -- http://www.aonix.com