Debugging in Plain English? 274
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.
Specs in plain English (Score:3, Interesting)
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*
plain English development.... (Score:2, Interesting)
Now, there's a lot of reasons why this is a tough problem; English is tremendously less precise than a computer language, and a computer would need a GREAT deal of common sense before being able to make good sense of our high level spoken descriptions.
But still...so many programming tasks are really 95% "lather, rinse, repeat", and we're striving to get Design Patterns in place for much of the rest. It really makes me wonder...
For the history buffs, I think COBOL was one attempt to bridge spoken "Businessese" and computer code. I don't know a ton about it but I think it might ultimately be an underrated attempt... (for a while, all computers were financial (base 10 for its math, usually) or scientific (binary)...over time, the scientific approach 'won out', probably because it was easier for the scientific side to emulate the business side than vice versa, or maybe because the attention span of geeks is more important than who's writing big checks. Anyway, today's Unix culture is firmly from that scientific tradition, dot com boom not withstanding...
Thus endeth the less-than-full-assed history lesson and speculation about where this stuff will end up...
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.
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.
Sounds like InterScope (Score:2, Interesting)
You could ask InterScope questions like "Who calls FOO?" or "What function called by BAR stores into ZOT?". It answered by referring to a pre-computed database. Naturally, this kind of thing was made easier by the fact that LISP programs are represented as LISP data structures.
One really has to ask whether there's anything really new in The Whyline [cmu.edu] apart from a pretty interface.
Re:The ultimate debugging tool: (Score:3, Interesting)
Re:Specs in plain English (Score:3, Interesting)
The problem is that its not an efficient language for dealing with math. Its extra verboseness makes it harder to write and maintain, for very little gain (If a person isn't going to write and fix code, who cares if he can read it?)
Re:Specs in plain English (Score:4, Interesting)
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.
Re:Not to appear smug but... (Score:2, Interesting)
Better yet, pay $40/hr for a real mechanic who knows when the computer is full of shit and fixes what's actually wrong, instead of the $30/hr fly by night trade school grad who fixes what the computer says is wrong, charges you for it, then has to go back and fix what's actually wrong, and charges you for it.
KFG
Re:How do they answer these questions (Score:3, Interesting)
Everybody should know all about the Therac 25 [vt.edu]. Interesting reading even if you've never gotten past "hello, world!" in your programming career.
Buddha (Score:3, Interesting)
Why is it called Buddha? Because otherwise debugging Haskell means just staring at your code until you achieve enlightenment!
Silver Bullet (Score:4, Interesting)
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:Bad Bad journalism (Score:2, Interesting)
I wouldn't consider Alice a "language for children," since 20-something-year-old college students learn it and use it extensively. If you learned C++ in middle school, would you call it a language for children?
You call CNN "Bad Bad journalism," yet you leap to the wrong conclusion about a language you know nothing about. You mustn't be new here.
Re:"Why didn't this program work as expected?" (Score:5, Interesting)
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?
Re:Other languages are better than English (Score:2, Interesting)
Any good English class will demonstrate to you that this is considered to be a grammatical error. It's so similar to a dangling participle that I guess this could be called a "dangling prepositional phrase." It could be better written as "By means of his telescope, he saw her in the park," or "She had her telescope when he saw her in the park," just to name two examples. You're right though that other languages make it harder to be ambiguous. Really though the thing that annoys me most about English is that there is no gender-neutral third person singular (he/she/it) because the only neutral one is not used to describe people, so you hear people say "they" instead.