Forgot your password?
typodupeerror
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 @04:51PM (#9815696)
    "Because you can't code worth a damn."
    • At WPI, the main C compilers actually have an answer for the makefile "make love".

      The response was something like "Sorry I don't know how to make love".

    • by 0racle (667029) on Tuesday July 27, 2004 @05:51PM (#9816265)
      Programmer: "Why didn't it work?"
      Computer: "How should I know, I just do what I'm told."
    • Deja vue (Score:5, Insightful)

      by EmbeddedJanitor (597831) on Tuesday July 27, 2004 @06: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.

      • 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.
        • As natural languages go, English is a very imprecise. Unfortunately English seems to be the main language for software developers (with all that offshoring, things might changes).

          When I lived in South Africa I could speak pidgin Zulu and Xhosa and studied Xhosa at university. If I recall, Xhosa had 16 noun groups and seven tenses. This means that Xhosa is far less ambiguous as to the relationship between things. Verbs are spoken with the subject and object noun group prefixes attached. Thus the verb for "hi

      • Or, as the old saying goes, make it possible to program computers in English, and you'll find that most programmers can't write English.
      • Re:Deja vue (Score:4, Insightful)

        by Minna Kirai (624281) on Tuesday July 27, 2004 @06: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...
        • Re:Deja vue (Score:3, Informative)

          by fungus (37425)
          Easy to do using exception chaining [ucar.edu].

          " An exception chain is a list of all the exceptions generated in response to a single root exception (say, a SQLException). As each exception is caught and converted to a higher-level exception for rethrowing, it's added to the chain. This provides a complete record of how an exception is handled "

        • "Why did my window go away?"
          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

          Actually, I've developed something not too different than this.

          In my larger PHP projects, I use an error handler script that logs the sequence of errors in a memory array, allowing me to view the contents easily. The output looks something like this:

        • by EmbeddedJanitor (597831) on Tuesday July 27, 2004 @10: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.

      • Silver Bullet (Score:4, Interesting)

        by Hognoxious (631665) on Tuesday July 27, 2004 @06:47PM (#9816766) Homepage Journal
        Real debugging via a humna language (particularly English) is bullshit.
        Unless it's programmed in English. Now what do you call a program in English? A spec. And as Brooks said [amazon.com], half the problem is debugging the spec.

        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:Deja vue (Score:3, Insightful)

        by MalleusEBHC (597600)
        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. With
    • by mandolin (7248) on Tuesday July 27, 2004 @06:08PM (#9816401)
      "Why didn't this program work as expected?"

      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.

      • by wideBlueSkies (618979) * on Tuesday July 27, 2004 @08:56PM (#9817835) Journal
        I am the psychotherapist. Please, describe your problems. Each time you are finished talking, type RET twice.

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

  • by SeanTobin (138474) * <byrdhuntr@hotCOWmail.com minus herbivore> on Tuesday July 27, 2004 @04:51PM (#9815700)
    Mr. Debugger, 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.

    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!
    • by Anonymous Coward on Tuesday July 27, 2004 @04:58PM (#9815777)
      It looks like you're trying to dereference a null pointer during global destruction. Would you like to start the debugger?

      .__ /
      / \
      |@@|
      |\/|
      \__/
      • "It looks like you're trying to dereference a null pointer during global destruction. Would you like to start the debugger?"

        Well, this is a snippet from a response, but it really gets the core of the issue. Global destruction is a very stressful time to do just about anything. I'm by no means a programmer, and I have no idea what you're talking about, but don't you have better things to do when the end of the world comes? I'm even more alarmed if your 'threads' are actually causing global destructio
    • by Rosco P. Coltrane (209368) on Tuesday July 27, 2004 @05:01PM (#9815811)
      Help me O great plain English debugger. You are my only hope!

      I'm afraid I can't do that Dave.
    • by Tackhead (54550) on Tuesday July 27, 2004 @05:01PM (#9815814)
      > Mr. Debugger, 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.

      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)

      by SeanTobin (138474) <byrdhuntr@hotCOWmail.com minus herbivore> on Tuesday July 27, 2004 @05:02PM (#9815832)
      Hey moderators, this is NOT FUNNY! I've been wresteling with this problem off and on for nearly 3 months now. (I've come up with several varried solutions, but none of them are the way I want it to be done)
    • Two words for you: (Score:2, Informative)

      by _14k4 (5085)
      C
      Sharp

      Eww, I can't believe I just said that. I need a shower. I was kidding. Kidding. I use C# for text processing as much as I drive through New Jersey on purpose.

      Never.
    • by Anonymous Coward on Tuesday July 27, 2004 @05:22PM (#9816005)
      Hey there Sean,

      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" .. more like "business illogic".. HOLD ON!^G^G^G^G

      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 .. that one always cracks me up! I think it's time for a hampster dance revival. I'm defacing amazon.com right now and replacing the home page with the hamster dance (Linux is sooo easy to hack). We'll have a few hours of fun before the FBI shows up. I sure do hope all your files are written to the hard drive before Agent Scully pulls the power!

      HA HAHA HAHAAAAAA

      humans SUCK.

      • ...how about the compiler? One of my current random mutt .signatures is

        AI.cpp:33241: warning: You wrote 'neurons.merge(solution1, solution2)",
        AI.cpp:33241: you probably MEANT "neurons->merge(solution1, solution2)",
        AI.cpp:33241: but there is a MUCH better way to implement this whole
        AI.cpp:33241: function; doing that instead.

      • Ruby [ruby-lang.org] is awesome.
    • My name is Eliza. I am hear to help you with your problem. And how do you feel about that multithreaded perl app using perl 5.8.3?
  • by Anonymous Crowhead (577505) on Tuesday July 27, 2004 @04:52PM (#9815705)
    printf, System.out.println, warn, print, etc.
  • by oostevo (736441) on Tuesday July 27, 2004 @04:53PM (#9815713) Homepage
    Oh ... this will be wonderful for security the world over. If it works ... Microsoft Programmer: "Why does our software suck?" *computer hangs, then bursts into flames from the load*
    • " Oh ... this will be wonderful for security the world over. If it works ... Microsoft Programmer: "Why does our software suck?" *computer hangs, then bursts into flames from the load*"

      No, it will Bluescreen, which....while crashing, would also give a wonderfully ironic answer to the question at hand.

  • by mhore (582354) on Tuesday July 27, 2004 @04:53PM (#9815714)
    Because I debug in plain english anyway, I'm always saying "Why the hell won't you work you piece of shit?!" and "Listen here you piece of shit if you insist on seg faulting again then I'll show you where you can put those damn indices!"...

    So... now the computer can actually respond to my threats and questions. Excellent!

    Mike.
    (Yes, I did RTFA.)
  • by Anonymous Coward on Tuesday July 27, 2004 @04: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... [cryptonomicon.com] lately?).
  • by scowling (215030) on Tuesday July 27, 2004 @04:54PM (#9815730) Homepage
    [...] "Forty-two," said Deep Thought, with infinite majesty and calm.

    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 [...]
  • by mattkime (8466) on Tuesday July 27, 2004 @04:55PM (#9815739)
    WHERE THE FUCK DID MY THESIS GO??? ...if it can bring calm to these situations, we may have a contender for the Nobel Peace Prize.
  • by samsmithnz (702471) on Tuesday July 27, 2004 @04:56PM (#9815751) Homepage
    "Whyline, has been used only to debug programs in Alice, an academic programming language with a limited vocabulary of commands to make interactive 3-D worlds, like video games."

    "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...
    • by code_rage (130128) on Tuesday July 27, 2004 @05: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.
      • - Why did a radiation therapy machine zap patients with the wrong doses (inconsistent state between GUI display and internal software state)

        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.

        • Thanks for posting it -- this is the first time I've seen the story in this much detail, and it corrected some misconceptions I had about the case. In fact the root of the problem seems to have been a race condition between the user interface, the control software, and the hardware. This raises a very important point about critical, real-time systems: if you impose a software wait state that is designed to permit the hardware to reach some necessary state, be very careful and make certain that the wait stat
  • Response (Score:3, Funny)

    by Anonymous Coward on Tuesday July 27, 2004 @04:57PM (#9815766)
    Why didn't a program behave as expected?
    Because the expectations where wrong.
  • computers are too darn literal. :)
  • Yes, but... (Score:2, Funny)

    by maxchaote (796339)
    That's great, but does it understand expletives?
  • Computers will only be truly easy to use when they do what I mean instead of doing what say.

    Jason.
  • by Rosco P. Coltrane (209368) on Tuesday July 27, 2004 @04: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...
      1. Determine the problem.
      2. Create a hypothesis of the cause of the problem.
      3. Test the hypothesis.
      .
    • by kfg (145172)
      . . .but somehow it appears you still have to fork off $30/hr for the workmanship to get it fixed...

      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
    • 'Andrew Ko's invention is just another tool."

      And what if his tool has bugs of its own that prevent it from working properly?

  • pointless (Score:4, Insightful)

    by TedCheshireAcad (311748) <ted@[ ]rit.edu ['fc.' in gap]> on Tuesday July 27, 2004 @04: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.
    • Er, no. Whyline works with a (simplified, English-like) language called ALICE. Java is 10x more complex, thus making it difficult/impossible to get Whyline to understand Java. Ooh, I wonder where they got that "10x" from?
    • Good lord, this got moderated up? And to think I just used up all my mod points about 2 minutes ago. Read the damn article again. It says that Java is 10x more complex than Alice, the language for which the tool was developed.

      Go slashdot moderators!

      I mean it. Go! Go Away! If you can't be bothered to read the article attached to the story you're moderating, you're worse than useless.

  • Plain english or not, make it easy for someone to debug and I'll be out of a job. I like finding other people's mistakes and being the one to say "Uh, dude, this is where you screwed up, but I fixed it for you".

    Where's the fun if I can't point out someone's shortcomings?

  • by Mignon (34109) <satan@programmer.net> on Tuesday July 27, 2004 @04:58PM (#9815788)
    M-x doctor

    Why didn't a program behave as expected?

    Is it because didn't a program behave as expected that you came to me?

    C-x k
    • Actually, Emacs was sorely missing automation of this functionality. So I added it passed on psychoanalyse-pinhead. Feel free to run it on stack traces, debugger output or get it to do code reviews for you. Enjoy.

      (defun psychoanalyze-file (filename)
      "Send any file to the analyst."
      (interactive "f")
      (let ((tempbuf (create-file-buffer filename)) current-pos eob)
      (set-buffer tempbuf)
      (insert-file-contents filename)
      (goto-char (point-min))
      (setq current-pos (point-min))
      (setq eob (point-max))
      (doctor)

  • by lakeland (218447) <lakeland@acm.org> on Tuesday July 27, 2004 @04:59PM (#9815798) Homepage
    A couple years ago I was chatting to someone who developed a program where specs could be written in plain English. Specifically, Rational already has a spec language called controlled English that is simple enough for PHBs to _read_ (but not write, kinda the opposite of APL and perl ;-)

    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*
    • They tried that years ago. It was called Cobol.

      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?)
    • by jfengel (409917) on Tuesday July 27, 2004 @05:45PM (#9816217) Homepage Journal
      I'm not a fan of controlled English systems, because they're misleading. They are computer languages, not natural languages, and people often misunderstand the semantics. They are as exacting to write as code, but more verbose. If the controlled English isn't quite working, it can be intensely difficult to debug.

      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) :- parent(X,Z), parent(Z,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.
  • I think I'll stick to yelling at the machine when I'm trying to run "make" when a dependency gets left out of the ./configure script and it errors out after 5 minutes of compiling.

    "What the fuck is libmonkey1316-3.so??!!"

    Finding whole RPMs with the name of one known file you need is always fun. On second thought, maybe asking the computer what the hell that file is could help.
  • It seems like it has only been implemented in ALICE and not for any other languages such as Java or C, implementing it for these languages would be non-trivial. There have been many de-bugging tools over the years, none of them have fundamentally changed programming, so I'd wait and see if it is actually useful, or lives up to expectation. M
  • What'll be interesting, if a long way off, is when they get plain English development.

    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 w
    • 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'

  • by jeffmeden (135043) on Tuesday July 27, 2004 @05: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!
  • And this helps how? (Score:3, Interesting)

    by buckhead_buddy (186384) on Tuesday July 27, 2004 @05:01PM (#9815822)
    The article showed what looked to be a Pac-Man environment which tried to show objects (ghost, dot, pac), a boolean (why did, didn't), and a condition (move toward x). That is a cool idea to enhance debugging with holistic information about objects at a higher level.

    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.

  • by CAIMLAS (41445) on Tuesday July 27, 2004 @05: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.
  • Video editing [cmu.edu] for porn? Why else would they use that graphic? :)
  • Drink Me, Eat Me (Score:4, Interesting)

    by grunt107 (739510) on Tuesday July 27, 2004 @05:06PM (#9815874)
    From the pdf on whyline, it seems to work with the Alice language. Alice seems to be very rigid in its design, allowing English lookups (rather like naming variable in English-word format like 'pac_resize').

    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.

  • by GraWil (571101) on Tuesday July 27, 2004 @05:07PM (#9815886)
    debug> Why did my web server crash?
    reply> slashdotting
  • Brad Myers! (Score:2, Informative)

    by Teppy (105859) *
    Great to hear what he's up to these days. He's the third professor [slashdot.org] in this story from my days at CMU. Brad, if you're reading this, all that videogame stuff wasn't a waste of time after all. [ataleinthedesert.com]
  • by Tackhead (54550) on Tuesday July 27, 2004 @05:12PM (#9815923)

    So this whole article is about the UPS Debugger. Just One More Hack [colorado.edu], and then he'll put it on the 'net...

    Well, I've written a debugger and it suits me just fine It'll chase away your problems, turn your water into wine
    It's got so many features, in fact it's bloody clever,
    If it can't solve your problem then your problem probably never
    can be solved
    so you might as well pack it on in,
    coz it's the best debugger that there's ever been.

    It's got everything you wanted, everything you desire.
    It'll handle fancy structures, set your soul on fire,
    It'll indirect through pointers, and catch a falling star,
    and if you ask it nicely it'll pop off to the bar
    and tell your friends
    how to solve the problems they're in,
    coz it's the best debugger that there's ever been.

    If you've got a nasty problem and your data structure's bent
    and your pointer's in a tangle with your structure elements,
    If you're losing all your memory coz your allocator leaks
    And your girl's getting nasty coz she's not seen you for weeks,
    then stoke up Mark's debugger
    you know it'll win,
    coz it's the best debugger that there's ever been....

    MP3 version available at: Just One More Hack [nosuch.com] - Mark Wheadon
  • Sounds kinda like the ship computer in STTNG.

    Jordi: Computer, why didn't the warp field form?
    Computer: There was insuffient anti-mater to cause a stable reaction.
  • The Carnegie-Mellon University finally invented Clippy!!!

    Way to go.
  • Write the program perfectly the first time.
  • I can't do that, My prime DRM directive now insists I have to subdue you for intellectual copyright infringement, this won't hurt much...
  • "[if you have] used a Web application to fetch news about your hobby or favorite celebrity, you've programmed."

    No you haven't. Excel spreadsheet *maybe* counts like an instance of functional programming, but not using a freggin' web app!!!

  • 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 oc

  • by mdlbear (735185)
    Back in the last millennium, the early 1970's to be exact, there was a programming system called InterLisp. It had a fantastic error-correction system called DWIM (Do What I Mean), infinite selective undo, and (relevant to this particular post) an English-language query system called InterScope.

    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 t


  • You really only need one command..

    "Why?"

    So why bother giving people any choices in the matter? =)
  • It's Carnegie Mellon (Score:2, Informative)

    by tk2x (247295)
    Melon is a fruit..
  • by koali (175176)
    I think that this basically goes through the statements that are executed conditionally and tells you the condition that chose whether they were executed or not, that is:

    x=a;

    if(x==3) { printf("hello"); }

    Why did hello not get printed? Because x was 7, not 3.

    If it can track it further (i.e. because x was assigned the value of a on line 77, and it was 7 and that time... and a was assigned b+2 in line 44, etc. etc.), that would be mildly useful.

    In any case, I think that the debuggers that can step back in
  • Why didn't a program behave as expected?

    Well...I wonder how well the debugging in plain English worked when spelling "Mellon" is such an ordeal. Egads!
  • It would probably help if developers would throw exceptions with plain english messages that stated:

    1. What line in the source code the problem resides on.
    2. What data elements the program was trying to munch on and any file handles used/open during the fault.
    3. Depending on the language used, operating system handles and registers related to the problem.
    4. The name of the file/module and function/class involved.

    Finally, the application should always eat the error and continue on if possible (non segm
  • Buddha (Score:3, Interesting)

    by jbrandon (603700) on Tuesday July 27, 2004 @06:12PM (#9816429)
    Buddha [mu.oz.au] is a debugger for Haskell that displays, in a heirarchical fashion, every function call in your program, then lets you declare every function application and result as "Correct, Erroneous, Inadmissible, or Unknown". It can thus track down the error to a particular application of a prticular function.

    Why is it called Buddha? Because otherwise debugging Haskell means just staring at your code until you achieve enlightenment!
  • by Nurgled (63197) on Tuesday July 27, 2004 @06:16PM (#9816462)
    > My program crashed.
    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.
  • Programmer: What happened?
    Debugger: Windows crashed.
    Pr: Why did it crash?
    Db: Faulty code.
    Pr: (mumbles)I know that you stupid piece of s*!t...
    Pr: Can you show me the faulty code that caused this crash?
    Db: Yes.
    Pr: Show me the code.
    Db: One second while I compute the time needed......
    Db: .................
    Db: .......
    Db: It will take 4 Days 14 hrs. 34 min. and 12 sec to display the code. Do you want to continue?
    Pr: Nevermind. Show me the lines that did not cause the crash.
    Db: 10 rem Windows
    Db: 20
  • by totierne (56891)
    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 cardboardprogrammer.com 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 differen

Neckties strangle clear thinking. -- Lin Yutang

Working...