There is an interesting story on how NASA used similar techniques to debug a problem on Deep Space 1, from earth, they were using Common LISP, you can find a bit more detail in here (http://www.flownet.com/gat/jpl-lisp.html) look for 1994-1999 - Remote Agent. I remember one of the guys who worked on this gave a talk which was in youtube but I was not able to find it again.
Edit and Continue in Visual Studio is similar to that.
You can change the source code while the program is paused in the debugger, for instance in a breakpoint, and continue after your modifications.
Re:Debugging Lisp Part 1: Recompilation
by bainsfather on Wednesday July 08, 2015 @12:29PM
(#9852761)
Interesting, thanks.
Do you get the ability to move the execution point back to before the the error, in order to resume execution? - from what I can tell, this isn't possible - from https://msdn.microsoft.com/library/y740d9d3.aspx#BKMK_Set_th...
"Setting the next statement causes the program counter to jump directly to the new location. Use this command with caution:"
"If you move the execution point backwards, intervening instructions are not undone. "
Not sure, I have never tried moving the instruction pointer after Edit & Continue.
Moving the instruction pointer backwards has been fine in my experience if you choose a suitable line to reset your state.
> Do you get the ability to move the execution point back to before the the error, in order to resume execution?
You can in Visual Studio 2012 and in Visual 2015 some corner cases were fixed.
Just drag the arrow backwards with the mouse.
e.g. wading through clojure stack traces seems very primitive in comparison.
How important is it in practice? Can/could other languages do this?
As an outsider looking at new (to me) languages, it's hard to judge what the pros and cons of a language are - especially the cons - e.g. several years ago, when looking at clojure, it took a lot of searching before I concluded that clojure did not have this feature (maybe that has changed now?). Meanwhile the 'learn language x' books always seem to focus only on syntax, rather than workflow.