Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Programming Bug

Taking the Pain Out of Debugging With Live Programming 254

angry tapir writes "'Everyone knows that debugging is twice as hard as writing a program in the first place,' Brian Kernighan once wrote (adding: 'So if you're as clever as you can be when you write it, how will you ever debug it?') However, Sean McDirmid, a researcher at Microsoft, has been working to remove some of the pain from debugging. McDirmid, based at Microsoft Research Asia, has been studying ways of implementing usable live programming environments: a solution that is less intrusive than classical debuggers. The idea is to essentially provide a programming environment in which editing of code and the execution of code occur simultaneously — and in the same interface as code editing — with tools to track the state of variables in a more or less live manner."
This discussion has been archived. No new comments can be posted.

Taking the Pain Out of Debugging With Live Programming

Comments Filter:
  • by White Flame ( 1074973 ) on Monday April 15, 2013 @09:26AM (#43451817)

    This will no doubt become an ad hoc, informally-specified, bug-ridden, slow implementation of half of a REPL.

    • Yeah, yeah, reinventing LISP.

      Forget that, will this be reinventing, dunno, "MFC .NET", where software is effortlessly implemented, tested, and documented using a mix of object classes, C++ templates, custom extensions to C++ that break portability, "wizard" (i.e. obscure template) generated code, a virtual machine, and calls between "managed code" on the virtual machine and native code that break security and prompt stern security scoldings when your code is on a virtual drive or "network share"?

  • I've been using this amazing technique for a long time now, IDEs like Eclipse make it fairly easy to do that. TFS doesn't explain what is it that he is doing differently.

    • Yeah. This sounds just like a profiler, which has been around forever. Is there something new here, or am I totally off base here?
    • OK, in Eclipse, how do I code & run at the same time.

      I can alter things in the debugger and push them back to the live application, but I can do that in VS too. This is reading more like Python/Lisp, where you can edit as you run, and (as with some of their IDEs) the code gets saved to source files for later use.

      • OK, in Eclipse, how do I code & run at the same time.

        Type and save it?

        • Umm... You can do that in Visual Studio also.

          My suspicion is it's something slightly more integrated, like you can see with a CLI interpereter in Python or Lisp. Particularly the latter, where you just code, and when you are done, you have have it save the most recent version of ever function into a file.

  • Good, but... (Score:4, Insightful)

    by ControlFreal ( 661231 ) <niek@ber[ ]er.net ['gbo' in gap]> on Monday April 15, 2013 @09:31AM (#43451871) Journal

    ... this should be in addition to good coding/style standards, proper design, proper source revision control, proper code reviews, and continuous testing/integration. Without any of the former, using this tool does not provide that much information: You first want to know whether your code does what you think it should do, whether it is thread safe, whether it is leaking memory, etc., etc., etc.

  • Prograph did this in the early 1990s. Way to innovate, Microsoft!

  • by Anonymous Coward

    and it wants Smalltalk back.

    https://en.wikipedia.org/wiki/Smalltalk#Image-based_persistence [wikipedia.org]

  • Wow (Score:5, Funny)

    by LizardKing ( 5245 ) on Monday April 15, 2013 @09:34AM (#43451913)
    They've reinvented Smalltalk. Let's party like it's 1980.
    • Sounds more like they reinvented the Python console...

      Or, you know, bash.

      Any shell, reallly.

      • by Splab ( 574204 )

        If you think debugging in the console has anything to do with debugging, you are missing out.

        Connecting a debugger to python and stepping through your code is by far the smartest way to figure out what the freck is going on - no printing xyz all the time to see what happens. You just put a break point and you will have all the juicy goods, including stuff you didn't think of looking at.

        Personally I use IntelliJ with the Python plugin (essentially PyCharm), it rocks.

        • by ceoyoyo ( 59147 )

          Yes, that's one way. It can be useful. Another way is just to put a code.interact() in as a breakpoint and then paste or type lines in as you go. That way if you find a bug you can fix it and continue without restarting the program. Which is what I assume the article is talking about, except with a nice GUI plastered on top.

  • Though not quite the same I like an IDE (like Eclipse) for Live Syntax Checking. What makes it better than a text editor is that It can check syntax on the fly, and remove some of the edit/compile/broken-compile/swear/re-edit/recompile loop.

    No, it's not as cool as potential Live Running, but it helps a lot to keep your mind on code flow rather than language syntax.

    • by CastrTroy ( 595695 ) on Monday April 15, 2013 @10:22AM (#43452355)
      Welcome to VB.Net. It's been there for ages. Mind you you have to pause the debugger to edit the code, but that's probably a good idea anyway. VB.Net also has some of the best pre-compile (it has a background compiler) syntax checking of any language I've ever seen. The only time you actually have to compile the program is when you want to run it, you never have to compile to make changes show up for auto-complete. And once you're running in the debugger you can edit the code anytime the code is stopped. There's a few limitations. I'm not sure if you can add a whole class while it's running, but you can definitely fix all those little off-by-one errors and continue running the program.
  • So, it's a spreadsheet, basically? It isn't a bad idea at all.
    • Reminds me of batch files, personally. As long as the script runs in a loop of some sort, you can have Notepad open to edit the script while it's still running. I think shell scripts are the same way, although I haven't done much with shell scripts in years.

  • VIM editing Perl code in one window, another for an execution trace, and a third to run the program. Ugly and basic but it gets the job done.

  • how would it integrate data/network/user input?

    how does it know when to start live testing, as pieces of interdependent code are being written?

    • I was wondering about this myself. I would have it generate "fake" sample data, much like "previews" work for reporting enviromnents (Tableau and OBIEE for example). A wee bit difficult to implement that for networking, but user input can be easily interpreted (the GUI allows you to set some defaults) and regular data input can be set up through data templates (use this table, use that CSV, etc).

  • by waddgodd ( 34934 ) on Monday April 15, 2013 @09:48AM (#43452045) Homepage Journal

    "a programming environment in which editing of code and the execution of code occur simultaneously" is commonly called an interpreter, welcome to 1975

  • For I have been looking for one, lo, these past 27 years.

  • I do not code or develop code any more, but I'm great for finding bugs in code which irks my developers to no end. But conversely, they really like when I test their code, especially when they want to have bugs found. I know how to recall what I did when creating my bug report. I almost never report something as a bug until I can repeat the issue and then I usually re-create the issue two more times to ensure I recall just how I got to that bugged state. I document step by step instructions and follow i

    • The problem is that most corporations reduced UAT and bugtesting to... nothing, really. They just launch the product and then patch it endlessly, basically using their customer base as bug testers.
      I've seen bugs in end products that were ridiculously OBVIOUS, e.g. the program wouldn't install on ANY x64 Windows OS (XP, Vista, 7). That's the sad state most software products are in right now...

  • Fred Brooks noted this one years ago, and it's still true: The reason programming is complicated is frequently because the real-world problem you're trying to model in software is complicated. The reason debugging is even more complicated is that not only do you need to understand what you're trying to model, you also need to understand exactly how the existing software modeled the real-world problem.

    • ... you also need to understand exactly how the existing software modeled the real-world problem.

      Well... usually how the existing software failed to model the real-world problem. (That and understanding the difference between the code and the comments, never trust the comments.)

    • by gweihir ( 88907 )

      Very true. All this tool does is to suggest to people of even lower skill level that they can be programmers.Writing good code is hard and one way to learn avoiding making mistakes is if mistakes have consequences. With this tool, even more people will start to use an experimental approach to coding, where thinking about what they want to do beforehand is not part of the process anymore. That can only lead to disaster.

  • At first glance, I just want to say, "Hey, Basic Interpreter from the 70's, you're finally getting some respect!"
    But there are some deep issues that are, even with these techniques, going to be very hard to debug:
    1) Large I/O situations -- real time data collection and display. Weather reporting, gaming, etc. How is debugging on the GPU going to be helped by this, would be one of my first questions.
    2) Networked, distributed code -- with clients on multiple platforms (CPU, browser, Java version, etc.), and

  • Cool, I knew this would make a comeback from the 60s or something.

    • Or IBM's APL interpreters from the end of the same decade. Talented programmers have known what a debugging environment should provide for more than 40 years. Interpreted languages got there first, for all the obvious reasons. Same stuff just keeps getting reinvented for different languages and systems. That doesn't mean the new stuff isn't good, it just means it's not really new.
  • Pretty sure these were features of VB6. I remember hacking out code, using the immediate window to trace values, setting break points, stepping through the code, modifying in the middle of execution, and then resuming execution. The language itself may have had a lot of issues and performance issues, but the IDE and development environment had some very nice features.
    • by DarkOx ( 621550 )

      Your memory is a bit off. You could modify variables, call subs, functions, that might change values from immediate while stepping or stopped on a break point. You could not change code; though.

  • The problem is that so many programmers need debuggers in the first place. That is a sign of low competency levels. I found that using methods from design by contract basically eliminate the need for debuggers as they lead to much, much better code and give you errors that are directly meaningful. Of course, this requires thinking about what you want to program before doing so, as you are actually implementing a check of its implementation before you implement the actual code. And it can be done in any lang

  • by Chirs ( 87576 ) on Monday April 15, 2013 @10:17AM (#43452311)

    I just want the ability to detect a fault and then run my entire system backwards to figure out where the problem came in. Wind River Simics can do this, but it's expensive and time-consuming to get a model of your hardware unless it happens to be something they already support. It's also slow to run (as you'd expect).

  • Hah, this techinque is called PHP+println() and is not new by any means. I programmed PHP live with 50-100 clients ready to kill me if i clicked Ctrl-S a bit too early. Noobs.
  • This looks soooo much like the way smalltalk engines where implemented in the 80's it's boring.
    One can always count on MS to bring the latest in software innovation

  • Just as I am crunching down on my last bunch of some 40 odd bugs to make it for the release such news stories come as a welcome day dream. I am sure there are products where you could edit source code while running and the running code dynamically responds to code changes.

    But the most difficult bugs are not the crashes or randomization introduced by the thread completion order. What is difficult is the bug that happens after several hours of computation. Longer it takes for the bug to manifest itself, har

  • McDirmid notes that there are limitations to his prototype. For example, the approach used by LPX won't work for "interactive programs whose inputs consist of time-ordered events and whose outputs can vary over time

    You mean, such as programs which offer a user interface, and which both write to and read from some kind of persistence layer or document storage on the backend?

    Well, at least there can't be too many of those....

  • by CODiNE ( 27417 ) on Monday April 15, 2013 @10:33AM (#43452463) Homepage

    What's funny about this article is it's focused on a very limited text based debugging system where the author is already apologizing for bugs while demo'ing it.

    It mentions a quote from an Apple guy on the same topic. Wait a minute... Apple is working on this too? So you click the link and find a much better article with a similar system that's way more advanced and live connects the graphics with the code.

    Just kind of sad, I RTFA and think "Huh, that's interesting, someday" then check out the link inside the article and find a much more informative and interesting story that I'm still reading. Read THAT article instead. Looking forward to seeing this creep into Xcode updates.

  • My first suggestion would be is for them to implement WinDbg in an actual usable way. The cryptic commands and setting up the directories for the source and .pdb files.....sheesh.

  • The idea is good, but not new : http://vimeo.com/36579366 [vimeo.com] (Bret Victor's Inventing On Principle)
  • Not for sure I agree that debugging is harder than writing code.
    Writing GOOD code is hard. Debugging good code is easy.
    I've always enjoyed debugging and assuming the code is
    decently written, I usually find it fairly easy to track down and
    fix a bug.

  • The idea is to essentially provide a programming environment in which editing of code and the execution of code occur simultaneously — and in the same interface as code editing — with tools to track the state of variables in a more or less live manner."

    Not that I'm a Luddite resisting new tools and ideas, but wouldn't a REPL be good enough for most cases? Most of my professional life I worked with separate editing, compiling and debugging sessions, a necessary PITA for the tools at my disposal. But ever since I started using/playing with languages that come with a REPL (Python, Ruby, Scala), it's been like a productivity blessing where one can break portions of the code into (semi)independent, coherent groups of lines that can be tried out again and again

    • Its 100x better for this than any of the languages you mention, higher performance, generally, and achieves VERY high rates of internal reusability to boot. I literaly wrote 4.5 million lines of fully debugged functioning FORTH code in 5 years. It certainly isn't a FASHIONABLE tool, but its frighteningly effective.

    • by lytles ( 24756 )

      i totally agree with you wrt the value of a REPL. i've done a fair amount of work in matlab, and i would mock up a method and work in the command line interface while stopped in the debugger until i got something working and then paste it back into the editor

      beanshell2 for java isn't bad, but it's not integrated into the debugger so it doesn't help much. i use netbeans as my IDE and the "evaluate expression" debugger tool is decent for java, as is gdb for c. but all 3 pale in comparison to the matlab enviro

  • Anybody have an explanation about how this is different than what LLDB and LLVM can do? You can debug running code and modify the executable on the fly already.

  • Didn't Chuck Moore implement this already 20 years ago?
  • So, now the developer has this great tool that runs on their desktop that helps them debug the program. Now what happens when it fails in the field? Did the developers spend the time to create sufficient tracing/logging functions so that the end user can report the failures?

    The largest problem isn't "debugging" during development, its "debugging" post failure analysis of field problems. Its such a large problem that nearly all "software engineering" and related process is focused on moving the debugging asp

  • So, he's reinvented FORTH 50 years later and using 5000x more lines of code, and FORTH still does it better! ROFLMAO! Ah, Charlie Moore, I doubt you read /. but you will never be dethrowned as the author of the most elegant code ever. Thx!

"To take a significant step forward, you must make a series of finite improvements." -- Donald J. Atwood, General Motors

Working...