Ada Home
May 29, 1997
by John W. McCormick
mccormick@cs.uni.edu
In the April 1997 issue of the Communications of the ACM ("My Hairiest Bug War Stories", CACM 40(4):30-37, April 1997) Marc Eisenstadt analyses the types and methods of locating bugs in war stories he collected on the net. He asked people to send him descriptions of thorny bugs in large pieces of software that caused them a lot of of headaches.
Looking at the three examples of bug stories in the article I thought that 2 of those 3 bugs would have been detected in an equivalent Ada program at either compile or run time.
Since Marc Eisenstadt has made all of his collected war stories available, I was able to make the following quick analysis of 41 bugs in 39 of his Usenet stories:
For Ada to detect 15 of the 17 bugs located in the programs is a pretty good batting average.
Editor's note: This is one more piece of evidence that Ada is one of the best programming languages when it comes to the early detection and correction of errors --a quality due to language design, not accident. But many programmers are still unaware of this fact, and even the author of the "Hairiest Bugs" paper seems to ignore the influence of programming languages (much of his emphasis is on the improvement of debugging tools, i.e. curing the symptoms rather than the disease). Nancy Leveson once said during a keynote speech at OOPSLA that Ada is a good language for the development of safe systems (by contrast with more popular programming languages). Ada can eradicate a large proportion of common programming errors ("bugs") at the outset. Can you think of ways to get the message across?
Here is the original abstract of Marc Eisenstadt's article:
A worldwide trawl for debugging anecdotes elicited replies from 78 respondents, including a number of implementors of well-known commercial software. The stories included descriptions of bugs, bug-fixing strategies, discourses on the philosophy of programming, and several highly amusing and informative reminiscences. An analysis of the anecdotes reveals three primary dimensions of interest: why the bugs were difficult to find, how the bugs were found, and root causes of bugs. Half of the difficulties arose from just two sources: (i) large temporal or spatial chasms between the root cause and the symptom, and (ii) bugs that rendered debugging tools inapplicable. Techniques for bug-finding were dominated by reports of data-gathering (e.g. print statements) and hand-simulation, which together accounted for almost 80% of the reported techniques. The two biggest causes of bugs were (i) memory overwrites and (ii) vendor-supplied hardware or software faults, which together accounted for more than 40% of the reported bugs. The paper discusses the implications of these findings for the design of program debuggers, and explores the possible role of a large repository/data base of debugging anecdotes.
If you read Marc Eisenstadt's article in the CACM "Debugging Scandal" issue, write to the author (see Resources below) and address your email letter-to-the-editor to Diane Crawford, executive editor of CACM; her email address is listed near the top of page 5 of that issue (note: this is NOT a call for flames, send only constructive comments please).
| Do you have stories to share where Ada saved (or would have saved) a project? email to the Ada Home editor |
Page last modified: 1997-05-30