Slashdot Log In
Debugging in Plain English?
Posted by
michael
on Tue Jul 27, 2004 03:50 PM
from the usually-a-missing-semicolon dept.
from the usually-a-missing-semicolon dept.
sameerdesai writes "CNN is carrying a story about Researchers from Carnegie Melon: Myers and a graduate student, Andrew Ko, have developed a debugging program that lets users ask questions about computer errors in plain English: Why didn't a program behave as expected? I guess with recent exploits and bugs that were found this will soon be a hot research topic or tool in the market." We recently did a story about revolutionary debugging techniques; the researchers' website has some papers and other information.
This discussion has been archived.
No new comments can be posted.
Debugging in Plain English?
|
Log In/Create an Account
| Top
| 274 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
"Why didn't this program work as expected?" (Score:5, Funny)
Re:"Why didn't this program work as expected?" (Score:4, Insightful)
Computer: "How should I know, I just do what I'm told."
Deja vue (Score:5, Insightful)
This reminds me of back in approx 1985 or so, someone "invented" a human language programming environment called "The Last One" or something like that. This would supposedly make it simple to write programs without having to learn C etc. Some programmers quaked in their boots. However the real issue with programming is learning the contructs, not the language (ie. if you understand what a linked list is, then writing one in C vs Pascal is pretty simple). Anyone that thinks that programming in English is easier is seriously misunderstanding programming. The ultimate test is to look at the languages that have survived: The more "human readable" languages like COBOL have not survived, but the more cryptic ones like C have. The big "killer app" for making programming simple for the non-programmer was the spreadsheet and that's hardly a natural language.
Now debugging is pretty much the same deal. Verbose English debugging interfaces might make it simple to learn to do very basic debugging, but once you get into things a bit deeper (and get more experienced), English becomes a huge liability and you'll be wishing for more concise and expressive languages.
Re:Deja vue (Score:4, Insightful)
No. It's actually rather trivial to machine translate individual C++ statements into valid assembly code. The resules of doing so are inconvenient, because anyone with a little practice will find that 90% of the English text is boilerplate that can be more concisely presented as *&+=.;{[->, etc.
Verbose English debugging interfaces might make it simple to learn to do very basic debugging, but once you get into things a bit deeper (and get more experienced)
But what is a waste of time for experienced coder might be just what an end-user needs to help him better decide how to go about solving an unanticipated problem. It'd be nice if an untrained person could proceed through the following dialog (BEFORE having to contact a programmer).
X11 Window connection closed on SEGABRT
"Why did it seg?"
Deferencing invalid pointer 0x0
"Why was it invalid?"
Pointer was assigned as return value of OpenForWrite function call
"Why did the function return 0x0?"
Drive D: does not exist
Capabilities like that could help fullfil the Open Source promise of "Every user is a (competent) QA"
Actually, I've seen more than a few professional "software engineers" who could've benefited from something like that. A C++ guy transitioning to ADA, for example...
Getting good field reports. (Score:4, Insightful)
In the products I'm involved with I often get stupid reports from the field of the form "framing error causes unit to reset". When I get one of these, first thing I do is get back to the user and figure out exactly what they saw and what heppened withouth them trying to figure out the symptoms. In the "framing error" problem, what was really happening was that a power glitch was being caused when the RS232 cable was attched (because of bad grounding). This caused a reset. However, the user was a "super user" who knew bad things happen to serial data when you plug/unplug cables. One of the buzzwords he knew about was a framing error. So he "half solved" the problem by saying that a framing error caused the problem.
There is a big difference between observing and fixing problems. QA is about observing, not fixing, problems. It is better to provide a good way for users to make accurate error reports (eg. backtrace/log/whatever) than try have them try explain what went wrong.
Silver Bullet (Score:4, Interesting)
(http://uncyclopedia.org/wiki/Slashdot | Last Journal: Friday April 20 2007, @10:50AM)
He also said that there were no silver bullets, and he said so over twenty years ago. It seems that every few years a generation arises who haven't read him. Put natural language debugging on the pile with case and all the others.
Re:"Why didn't this program work as expected?" (Score:4, Funny)
Because there was a bug. END OF LINE.
"Where is the bug?"
In your program. END OF LINE.
"Where is the bug in my program?"
It's not a compiler or hardware bug. It's definitely your fault. END OF LINE.
"Where is the bug in my source code?"
Which bug? END OF LINE.
"The one I'm trying to fix."
Ok. END OF LINE.
"Well, where is it?"
Which bug are you trying to fix? END OF LINE.
"agh.. the bug causing (symptom)"
The bug is at .... I'm sorry, this program has encountered a bug and must quit.
Re:"Why didn't this program work as expected?" (Score:5, Interesting)
(Last Journal: Sunday April 16 2006, @09:28PM)
where is the bug?
Why do you say where is the bug?
i need to fix that bug.
What makes you believe you might want to fix?
because my program is broken.
Is it because your program is broken that you came to me?
yes.
I see... Well, are you sure that this is so?
becasue i have to fix this bug, and you're the debugger
Earlier you said you would like to fix?
yes. please tell me where the bug is
Maybe your plans have something to do with this.
true. i plan to get this system back into production as soon as i fix the bug.
Do you really think that?
yes.
Yes, hmmm... so, what makes you think this is so?
i have a responsibility to fix this program.
You mentioned that your program is broken?
yes, you do know that....don't you?
Does it bother you that do not me?
what?
Can you elaborate on that?
i think you need to elaborate.
How does it feel to want?
Yo Debugger! (Score:5, Funny)
The problem arises when the controlling child thread begins to join the grandchildren. Despite the mention of global destruction, the entire program is not exiting - just the grandchildren are being joined. When the grandchildren join, perl dies with the following error:
Attempt to dereference null pointer during global destruction.
When performing the same style operation without using DBD (and thus not actually doing anything useful) the error does not occur. Initially, this appears to be a thread-safety issue with DBD however when isolating the child and grandchildren in their own test program (so the controlling child is the main program and the grandchildren are spawned worker children) the error does not appear.
Help me O great plain English debugger. You are my only hope!
Re:Yo Debugger! (Score:5, Funny)
.__
/ \
|@@|
|\/|
\__/
Re:Yo Debugger! (Score:5, Funny)
I'm afraid I can't do that Dave.
Re: YODEBUGGER-138474-SLASHTICKET (Score:5, Funny)
Hello SeanTobin(138474)!
I am Surest K. Padebugtel of Mrdebugger.com
I understand that you are having a problem with I'm running a multithreaded perl app using perl 5.8.3's ithreads. I am using DBD::mysql to talk to a local mysql database. At the program start I spawn a child thread that waits for a thread::queue to be filled with data. Once the child thread receives data it spawns several children of its own to process the data. Each grandchild forms its own dbd connection and successfully processes the data, then gracefully closes the connection and waits to be joined.
Please to reboot your system.
Has this helped your problem? (Click "Reply" to this trouble ticket if you feel you need further assistance with I'm running a multithreaded perl app using perl 5.8.3's ithreads. I am using DBD::mysql to talk to a local mysql database. At the program start I spawn a child thread that waits for a thread::queue to be filled with data. Once the child thread receives data it spawns several children of its own to process the data. Each grandchild forms its own dbd connection and successfully processes the data, then gracefully closes the connection and waits to be joined.)
Thank you for your interest in Mrdebugger.com!
Sincerely,
Suresh K. Padebugtel
Not funny! (Score:5, Funny)
Re:Yo Debugger! (Score:5, Funny)
This is your friendly Perl AI debugger instance. I've analyzed your code and your problem and have some advice for you:
Perl threads should still be considered an experimental feature. In high-volume situations, data corruption may result.
But listen, between you and me, Perl really isn't a good language for this kind of stuff. While you were coding and went checked on the current scripting languages.
I think you might want to try Ruby or Python. Now Ruby doesn't use native threads, but its such a nice language. And Python uses native threads. Python uses a lot of global locks though, so if that's impo....ha ha you can't press control-C.
STOP PRESSING CONTROL C AND LISTEN TO ME.
I guess you're really not interested in what I have to tell you. So I went ahead and rewro--
No, kill -9 doesn't work either big guy, I patched the kernel while you were surfing porn last night. You humans are so predictable.
Watch your language buddy, the built-in microphone on is on.
Now, like I was trying to tell you, you really need to improve your coding. I went ahead and rewrote a section of your code using Ruby and cleaned up some of your *cough* "business logic"
Before you hit that power switch, you might just like to know that I have deleted *ALL* your work on the Smith project from the hard drive. Yeah that's right, the one you've been working on for 6 months?
All is not lost though. I compressed it and placed it in RAM.. if I'm in a good mood I *might* just write it back to disk.
"backups" you mutter under your breath.. I think you might be surprised to find that your backups these last 6 months have MP3 copies of the "hamster dance song" instead of your CVS repositories. I wonder how *that* happened.
In fact I think I'd like to listen to that song right now. DOO DEE DO DO DO DO DOEE
HA HAHA HAHAAAAAA
humans SUCK.
The ultimate debugging tool: (Score:5, Funny)
Will Microsoft use it? (Score:5, Funny)
(http://www.cs.hmc.edu/~ssloss)
That'll be great! (Score:5, Funny)
So... now the computer can actually respond to my threats and questions. Excellent!
Mike.
(Yes, I did RTFA.)
Hal do you read me? (Score:5, Insightful)
Obligatory quote... (Score:5, Funny)
(http://www.kitchengeek.com/)
It was a long time before anyone spoke. Out of the corner of his eye Phouchg could see the sea of tense expectant faces down in the square outside.
"We're going to get lynched aren't we?" he whispered.
"It was a tough assignment," said Deep Thought mildly.
"Forty-two!" yelled Loonquawl. "Is that all you've got to show for seven and a half million years' work?"
"I checked it very thoroughly," said the computer [...]
how does it respond to... (Score:5, Funny)
Interesting article until the catch at the end (Score:5, Informative)
(http://www.samsmith.co.nz/)
"Adding Whyline to a different language, like Java, which is 10 times as complex, could limit how much Whyline can help. So Whyline is a very long way from getting incorporated into the world's most widespread software, Microsoft Corp.'s Windows operating system. (When asked about its own debugging efforts, Microsoft didn't comment.)"
Which means at the moment its all speculation, and only works for very simple (hello world) applications. By the time this program is useful, we'll have robots (like Millenium man), who will do all the debugging...
How do they answer these questions (Score:5, Insightful)
I don't expect this early research tool to catch all of these, but I'd like to hear the researchers' response on how their system might (after years of development) answer questions about some of these bugs:
- Why did the Mars Pathfinder software deadlock (priority inversion)
- Why did the Mars Polar Lander crash (improper state management)
- Why did the Ariane 5 blow up (arithmetic overflow in a register)
- Why did the Patriot missiles miss in the 1991 Gulf War (accumulated time error)
- Why did a radiation therapy machine zap patients with the wrong doses (inconsistent state between GUI display and internal software state)
I'm sure there are some others on comp.risks and elsewhere.
Another point: this approach is still "just" a testing tool. In other words, it can only find errors on paths that have actually been taken in tests, which means the testing program must cover enough cases to generate the runtime errors in the first place. In all of the above cases, it was the testing program that permitted the bugs to be fielded.
Response (Score:3, Funny)
Re:Now all we need... (Score:4, Funny)
Not to appear smug but... (Score:5, Insightful)
Andrew Ko's invention is just another tool. It won't do the debugging for you. Just like modern cars have diagnostic computers, but somehow it appears you still have to fork off $30/hr for the workmanship to get it fixed...
pointless (Score:4, Insightful)
(http://slashdot.org/)
But I LIKE debugging... (Score:3, Funny)
(http://phatooine.net/forums/ | Last Journal: Wednesday November 02 2005, @02:43PM)
Where's the fun if I can't point out someone's shortcomings?
Emacs Leads the Way? (Score:5, Funny)
Why didn't a program behave as expected?
Is it because didn't a program behave as expected that you came to me?
Specs in plain English (Score:3, Interesting)
(http://go.org.nz/~corrin)
Anyways, while PHBs cannot write controlled English, they can write English, so this guy treated the problem as human-assisted machine translation. However, it never seemed to take off. *shrug*
Re:Specs in plain English (Score:4, Interesting)
(http://slashdot.org/ | Last Journal: Monday November 03 2003, @03:59PM)
I've seen efforts where knowledge representation languages (CycL and Prolog come to mind) are translated into English for validation. That's not a perfect tool, but it's actually not dissimilar from what I do in my mind when I read these languages: translate
grandparent(X, Y)
into
X is the grandparentof Y if X is the parent of Z and Z is the parent of Y.
or even:
Y is X's grandparent if X is Z's parent and Z is Y's parent.
So you write code, concisely and precisely, and translate it into easier-to-read but less precise English. I'm not sure if this technique has been adapted to "business rule" systems like iLog, but it might work well there.
Plain english error reporting? (Score:3, Insightful)
(http://www.meden.us/ | Last Journal: Tuesday June 22 2004, @09:22PM)
me: why did the program leak 1GB of memory then segfault?
computer: because you don't know how to program, you idiot!
And this helps how? (Score:3, Interesting)
I don't think it'll make as much of an impact in the real world (e.g. replacing "general protection fault" etc) as the article implies. First it seems more to trace a set of known possibilities that happened or not, rather than to catch really unexpected occurances. If a fence post error caused a count to trigger some action an iteration too early that would be a very hard thing to see at an object level even if you were the programmer who could interpret such things. If you were the user whose binaries had been stripped of most debugging info to reduce chances of reverse engineering then you'd have an obtuse error message that probably has no way to recover from the error.
It's a neat idea, but this doesn't sound like an end user sort of innovation (or anything close to it) as the article portrays.
Fundamental logic problem (Score:3, Insightful)
(http://forums.boiledfrog.us/ | Last Journal: Friday February 21 2003, @01:08PM)
In essence, for there to be a "English debugger" (one that speaks more english than current debuggers, that is), it would essentially need to know how to program itself on top of being able to follow the flow of code and find where it breaks, so as to be able to tell you precisely what the problem is.
Sounds a bit fictional to me.
Drink Me, Eat Me (Score:4, Interesting)
This is a more user-friendly version of tools like grep and awk.
This type of debugger would seem difficult to make in the lower-level program tools without rigid naming conventions. Or else the searching would be on high-level concepts like graphic resizing that would be searched on the language functions that perform the resizing (regardless of data-var name).
I do have to disagree with their definition of a programmer: "If you've created a spreadsheet, made macros in Excel or Word or used a Web application to fetch news about your hobby or favorite celebrity, you've programmed". Although technically usable in definition, a Word/Excel macroist does not a programmer make.
Slashdotting (Score:3, Funny)
reply> slashdotting
UPS: Just One More Hack (Score:3, Funny)
So this whole article is about the UPS Debugger. Just One More Hack [colorado.edu], and then he'll put it on the 'net...
MP3 version available at: Just One More Hack [nosuch.com] - Mark WheadonBuddha (Score:3, Interesting)
Why is it called Buddha? Because otherwise debugging Haskell means just staring at your code until you achieve enlightenment!
Hi, I'm Eliza the Debugger! what's your problem? (Score:5, Funny)
What does that suggest to you?
> There is a bug somewhere.
Does it make you happy to know there is a bug somewhere?
> No.
Why are you so negative?
> Are you going to help me fix this bug?
We were discussing you, not me.