Slashdot Mirror
Taking the Pain Out of Debugging With Live Programming
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."
seriously? Now I admit that Visual Studio is feature rich, only on windows, only with microsoft stacks, and doesn't compile things in a normal fashion (see #pragma) this above comment just oozes microsoft troll...
Have you tried the new VS2012? They took a shotgun to the UI and the file menu is still screaming from the trauma.
They've reinvented Smalltalk. Let's party like it's 1980.
Apparently you're a troll? A weird one, because I kind of agree with you (except about Express: yes, it's free, but it's also so limited as to be basically crap.) VS *is* really the greatest IDE I've ever used. It's not perfect, but it is the best I've used. I obviously have not used every IDE ever, and I will also admit that it's much better at debugging .net code than unmanaged c++ code, but still. Microsoft has pushed a lot of crappy, worthless software, but VS 2008 was quality, and 2010 even better (apart from a couple minor UI mistakes, easily fixable with free extensions). Notably, at least far as the summary went, it's done everything this guy is claiming he invented, since basically forever. (Though I personally leave the "recompile on the fly" option turned off; I think it's more trouble than it's worth.)
I suspect you haven't seen a Common LISP debugging environment. Yes, they allow breakpoints, as well as live code modification. (And if you were lucky enough to have a LISP machine, you could dive into the code behind your libraries, your operating system, etc. -- updating state on the fly, all the way back to tweaking a driver on a running machine... on the fly, in LISP).
What we have these days (say, Clojure's nrepl) isn't as powerful as that, but it's pretty damned powerful even so. Want to tie into your production system and see what a new version of a function would do against currently live production data, without actually changing the production system's behavior? If you're writing purely functional code, you can do that trivially... and the language strongly encourages pure functional code (as opposed to many "modern" languages where trying to write things to be side-effect-free is working against the grain).
If the best example you can think of is QBasic, you have no idea what a REPL can do.
"a programming environment in which editing of code and the execution of code occur simultaneously" is commonly called an interpreter, welcome to 1975
Just because you're paranoid doesn't mean they aren't out to get you
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
Cwm, fjord-bank glyphs vext quiz
>What are the better alternatives?
Instrumented code.
Unit testing.
Live testing.
Rapid build - test turnaround.
If you're looking for a better debugger, you're doing it wrong.
You need to instrument your code with the features to make it testable from within the running code base.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Smalltalk-80 (or even Smalltalk-76) is more akin to what they seem to be describing than most lisp implementations. In Smalltalk-80, you can inspect every object in the system, visually, including the objects that comprise the inspector for whatever you're looking at, and you can modify any value on the stack, at any depth, unwind it and so on.
I am TheRaven on Soylent News