"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 – within the code editing environment – with tools to track the state of variables in a more or less live manner.
LPX combines editing and debugging not just in time but also in space: not only are debug results updated concurrently with our edits, but they are conveniently visible while we are editing.
"Traditional debugging techniques, like breaking and stepping with a debugger, are not compatible with continuous execution: debugger instruction stepping interferes with continuous live feedback, while the debugger’s need for a separate user interface to navigate and inspect execution necessarily disrupts the programmer’s focus on code editing," McDirmid writes in his paper, Usable Live Programming.
McDirmid's paper notes that his is not the first effort at live programming. However, in his view many efforts fall short by providing only live feedback of the output of a program's execution (or the execution of a section of a program). "[W]e cannot understand how a car is broken simply by observing how it drives," McDirmid writes.
Dead database walking: MySQL's creator on why the future belongs to MariaDB
Drupal 8: Re-architecting for world domination
Linux distro spotlight: Mageia
Contiki: An operating system for the 'Internet of Things'
AmigaOS 4 developer interview: Why it endures and what the future holds
The researcher quotes former Apple engineer Bret Victor, who wrote in a September 2012 article critiquing an online environment for learning programming launched by Khan Academy: "We see code on the left and a result on the right, but it's the steps in between which matter most. The computer traces a path through the code, looping around loops and calling into functions, updating variables and incrementally building up the output. We see none of this."
McDirmid's solution doesn't do away with this left-pane code/right-pane output approach altogether, but integrates much of the functionality found within a traditional debugger into the code editing window of his prototype development environment, which he has dubbed LPX ('Live Programming eXperience'): "LPX combines editing and debugging not just in time but also in space: not only are debug results updated concurrently with our edits, but they are conveniently visible while we are editing."
LPX makes use of two key concepts: Probing and tracing. The output from probing is integrated into the code editing environment itself, while tracing makes typical use of a
print()-style function to display continuously updated output in a separate pane or window.
@ operator in LPX, a programmer can add a probe to a function call, an expression or a variable, and the output of the probe will be shown just below the line where it's used. As code is edited, the output of a probe will be updated.
Because a particular code block affecting the value of an expression may be located within a function – and a function may be called multiple times within a program – the context of a probe can be fixed. So functionA(x) may calculate and return the value of log(x). Using LPX the value of any variables within functionA() and the output of the function may be linked to a particular invocation of the function – say,
functionA(12) – somewhere in the program. If code in a block is not reached during a particular function call, LPX can display it as struck out with a red line.
As the programmer edits functionA() or the linked call to functionA(), the output of the probe displayed within the code-editing window will be updated.
In the case of a function, say functionB(), that involves a loop, tracing using a print() function can be used to display constantly updated output in the secondary window to track the value of
j in a
for loop, for example.
LPX in action - view the full video here.
"Alone, neither probing nor tracing lead to a very satisfying debugging experience," McDirmid writes.
"For probing, a problem might be found after navigating through much of a program’s execution, which is tedious and not practical for large programs. Tracing has the reverse problem: it helps us identify problems but hardly tells us why it occurred without the finegrained code-based perspective that probing gives us. We then combine probing and tracing using the insight that the print statements that create trace entries are executed somewhere in the program—this execution place can then be used as an anchor for probing!"
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."
McDirmid concludes that although "existing live programming experiences are still not very useful" the area is emerging as "the next big step in programming environments".
"Many challenges remain in the realms of scalability, UI, and interactivity, but we believe that we have shown this experience to be useful so that future work will be worth the effort."
Follow Rohan on Twitter: @rohan_p