Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Programming IT Technology

Debugging in Plain English? 274

Posted by michael
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?

Comments Filter:
  • by Anonymous Coward on Tuesday July 27, 2004 @03:53PM (#9815719)
    Untill I can have a full conversation with a computer (a la the Turing effect, not the limited versions that Alice et. al. can accomplish) I'll be happy with source code, thank you very much. It's just another layer blocking me from the code anyway (read In the Beginning... [] lately?).
  • by Rosco P. Coltrane (209368) on Tuesday July 27, 2004 @03:58PM (#9815782)
    All these talks of "revolutionary" debugging techniques bother me a little. There's only one debugging technique, and that's the debugger's skill and experience. Debuggers, traces, logs and other printf()s and LEDs flashing are just tools.

    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)

    by TedCheshireAcad (311748) <ted AT fc DOT rit DOT edu> on Tuesday July 27, 2004 @03:58PM (#9815785) Homepage
    Article says adding Whyline to java makes it 10x more complex. Seems to me like just another example of Computer Science grad students trying to justify their existence.
  • by jeffmeden (135043) on Tuesday July 27, 2004 @04:01PM (#9815817) Homepage Journal
    How useful will this be when it responds to a simple question with a simple answer?
    me: why did the program leak 1GB of memory then segfault?
    computer: because you don't know how to program, you idiot!
  • by CAIMLAS (41445) on Tuesday July 27, 2004 @04:02PM (#9815828) Homepage
    There seems to be a fundamental logic problem with this kind of debugger. It seems to be more of an 'interpretive debugger' in which it would need to know what you're trying to do in the first place. Thus, it would have to know what the code -should- look like in order to tell you what the problem is.

    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.
  • by code_rage (130128) on Tuesday July 27, 2004 @04:14PM (#9815950)
    When I think about some of the bugs I have found (and coded), the Whyline approach seems very far-fetched. The degree of self-awareness (introspection) required by something like this makes it seem like the program would be able to avoid the trap in the first place. It would require the "analyst" or "observer" module to observe not only a stack trace and PC trail, but also would require the module to understand what is supposed to occur.

    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.
  • by powdered toast dude (800543) on Tuesday July 27, 2004 @04:24PM (#9816032) Journal
    I believe debugging output and error messages go hand in hand where improvements of this kind are concerned.

    In the area of error messages, we need a better balance between "understandable" and "informative". Today, it's usually one extreme or the other. Either error messages are too "friendly" to the point that they're rather meaningless (as in the notorious "Web site not found"), or on the other extreme, they're so "complicated" that the novice user has no idea what happened (as in "an xxx exception occurred at xxx, here is the stack trace, register states, and many many more confusing numbers").

    It would be nice if we (as a society that happens to use computers) could adopt a guide that gives the technically-savvy enough info to go on, but still helps the novices understand what went wrong in terms they can understand too. A balanced approach.

    Such an error reporting scheme, if successful, could almost certainly NOT be designed by marketing weenies nor by geeks alone, but through mutual collaboration and willingness to compromise on both sides. Hmm, no wonder it's so challenging.

  • by 0racle (667029) on Tuesday July 27, 2004 @04:51PM (#9816265)
    Programmer: "Why didn't it work?"
    Computer: "How should I know, I just do what I'm told."
  • by MenTaLguY (5483) on Tuesday July 27, 2004 @04:53PM (#9816286) Homepage

    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.

    Unfortunately it's because COBOL is excrutiatingly bad at expressing the sorts of things programmers need to express. It's not so hot for expressing business information either.

    I am reminded of the attempts to cross horses with zebras -- it worked, but the hybrid inherited the worst traits of each animal.

  • Deja vue (Score:5, Insightful)

    by EmbeddedJanitor (597831) on Tuesday July 27, 2004 @05:05PM (#9816379)
    Real debugging via a humna language (particularly English) is bullshit. The reason we have C, asm etc is because the concepts in programming are not easily expressed in English etc, but are far easier to express in a purpose-defined language. Likely the same applies to effective debugging

    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.

  • by xslf (10340) on Tuesday July 27, 2004 @05:17PM (#9816467) Homepage
    With these "natural language" languages, I always wonder- is English the only natural language out there? Doesn't look like it from the world around me.

    Then why all those "natural language" thins are in English?

    Seems to me that is easier to learn a programming language then to learn English for a non-native English speaker: much less ambivalence.
  • Re:Deja vue (Score:4, Insightful)

    by Minna Kirai (624281) on Tuesday July 27, 2004 @05:36PM (#9816663)
    The reason we have C, asm etc is because the concepts in programming are not easily expressed in English etc,

    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).

    1. "Why did my window go away?"

    2. 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...
  • by totierne (56891) on Tuesday July 27, 2004 @06:00PM (#9816876) Homepage Journal
    Explain your issues to a carboard cut out of a programmer and 50% of the time you solve the problem and the other 50% of the time you give a much better and more concise explanation to the next real programmer you have to explain the err unintentional feature enhancement to.

    I was going to write up a site with a flowchart with 20 questions to ask about a bug to clarify your thoughts. [I suppose both linux and windows can have a REBOOT as the first directive and what was the difference between now and when it was last working as the second, are you using the latest version of the code as the third has anyone else been working on these files the fourth.. well you get the idea, [it is like shooting fish in a barrel, but I have never seen it the full flowchart] that was in the dotcom era, when even a tiny good small idea like this was in someones mind a possible next big thing].

  • Re:Deja vue (Score:3, Insightful)

    by MalleusEBHC (597600) on Tuesday July 27, 2004 @09:01PM (#9818205)
    The reason we have C, asm etc is because the concepts in programming are not easily expressed in English etc, but are far easier to express in a purpose-defined language. Likely the same applies to effective debugging

    The problem isn't that the concepts in programming are hard to express in English. In fact, it's quite easy to express programming concepts in English. Why do you think pseudocode is so much easier to write and understand? The problem is that English does not have a context-free grammar. Without a context-free grammar, it infinite orders of magnitude more difficult to write a compiler for a given language.

    If someone were able to write a compiler for a natural language like English, it would be the most amazing advance in the field of computer science in years, possibly ever. Natural language recognition is some heavy stuff. But just because natural languages are more difficult for a computer to process, don't let this make you think that using computer languages makes it easier to "describe" your programs.
  • by EmbeddedJanitor (597831) on Tuesday July 27, 2004 @09:05PM (#9818236)
    This is nonsense. It is far harder to explain the concepts of SEGABRT, pointers,... to users than the English language interface. This won't help fixing problems either. In my experience have baked solutions/explanations from users are worse than useless. As a programmer I'd rather get a backtrace or an action log (ie a log file that shows what the user did and what went wrong).

    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.

  • by (142825) on Wednesday July 28, 2004 @12:49AM (#9819385) Homepage

    And what takes you between 2 and 3... and minimizes the number of attempts... is experience. Nothing more, nothing less.

    Sometimes it is relatively easy and little knowledge or insight is required. But some bugs require huge leaps of intuition to solve in a reasonable amount of time.

    To go from 1 to 2 is the hard part. But, you can use tools to instrument the problem and determine where the problem may be.

Stinginess with privileges is kindness in disguise. -- Guide to VAX/VMS Security, Sep. 1984