4 ms·
The JVM has supported the kind of environment you describe for more than a decade. Fire up IDEA or Eclipse, put a break point in your code and modify it at runt
by incepted 11y ago
The JVM has supported the kind of environment you describe for more than a decade. Fire up IDEA or Eclipse, put a break point in your code and modify it at runtime at your heart content.
You can even rerun portions of your code after you've modified it (rewind it), something that even Smalltalk never supported.
- lisper11 11y ago> The JVM has supported the kind of environment you describe for more than a decade. Fire up IDEA or Eclipse, put a break point in your code and modify it at runtime at your heart content. The JVM is a virtual machine targeted by many languages, some of which are dynamic, and Java isn't a "modern" static language from the standpoint of type theory and provability. In Pharo Smalltalk, for example, you can pause running code in the debugger and modify it using syntax the language doesn't actually support, and then, in the same runtime, open a class browser and modify the compiler to support the new syntax before finally accepting your changes in the debugger and resuming execution. You can swap every reference to one object with references to another object using become:, effectively swapping the identities of two objects globally at runtime. Perhaps all of this is possible in Haskell and the like, but it's still to be demonstrated. > You can even rerun portions of your code after you've modified it (rewind it), something that even Smalltalk never supported. Smalltalk and Lisp both support this.
- incepted 11y ago> Smalltalk and Lisp both support this. Interesting, do you have a few pointers?
- lisper11 11y agoFor Smalltalk, look at Pharo. For Lisp: http://malisper.me/2015/07/07/debugging-lisp-part-1-recompilation/ http://malisper.me/2015/07/07/debugging-lisp-part-1-recompil... http://malisper.me/2015/07/14/debugging-lisp-part-2-inspecting/ http://malisper.me/2015/07/14/debugging-lisp-part-2-inspecti... http://malisper.me/2015/07/22/debugging-lisp-part-3-redefining-classes/ http://malisper.me/2015/07/22/debugging-lisp-part-3-redefini... http://malisper.me/2015/08/05/debugging-lisp-part-4-restarts/ http://malisper.me/2015/08/05/debugging-lisp-part-4-restarts... http://malisper.me/2015/08/19/debugging-lisp-part-5-miscellaneous/ http://malisper.me/2015/08/19/debugging-lisp-part-5-miscella...
- incepted 11y agoNone of these links cover what I was discussing. The closest is part 4 ("restarting") but this section only describes code that can retry after a failure. I was specifically talking about debuggers that let you rerun code after you've modified it without having to restart your application, something that Java debuggers have allowed for almost ten years now. I continue to think that neither Lisp nor Smalltalk offer this functionality, can someone prove this wrong?
- lisper11 11y ago> I was specifically talking about debuggers that let you rerun code after you've modified it without having to restart your application, something that Java debuggers have allowed for almost ten years now. Java got this from Lisp and Smalltalk. The first and third links covers what you're talking about. For Pharo, which is graphical, just open the image, open the debugger on some code and modify it to your liking before clicking "Proceed," or alternately, pick an earlier stack frame and do the same. Did you even read this paragraph: > In Pharo Smalltalk, for example, you can pause running code in the debugger and modify it using syntax the language doesn't actually support, and then, in the same runtime, open a class browser and modify the compiler to support the new syntax before finally accepting your changes in the debugger and resuming execution. You can swap every reference to one object with references to another object using become:, effectively swapping the identities of two objects globally at runtime.