5 ms·

Common Lisp implementations allowed you to change your program's code while debugging decades ago. Microsoft added bare minimum of similar functionality like fi

by jhgb 5y ago

Common Lisp implementations allowed you to change your program's code while debugging decades ago. Microsoft added bare minimum of similar functionality like fifteen years ago or so, if I remember correctly. I'm not even sure they've caught up on class redefinition and instance upgrade at runtime yet, which has been supported in CL since the 1980s.

astrange 5y ago
Apple platforms used to have that ("zero-link") and removed it quickly because nobody actually liked it. I think this and Lisp/Smalltalk's image model is actually mistaken. It goes against the principle of "crash-only recovery" to try to recover from a bad state instead of being able to start over from the beginning.
- jhgb 5y ago
  Generally in CL you should be able to recover from a usable intermediate state and restart from there.
  - astrange 5y ago
    That encourages you to live off the intermediate image forever (like autogenerating code and then not maintaining the source for it), but if you miss some data corruption then you're stuck with it.
    - jhgb 5y ago
      You already are autogenerating code in Lisp (using macros), but not without keeping the source for it, which still lives in the source files. If those files are not loadable into a clean image, you're doing something wrong (like CMUCL people find out a long time ago).
fluoridation 5y ago
>Common Lisp implementations allowed you to change your program's code while debugging decades ago. Microsoft added bare minimum of similar functionality like fifteen years ago or so, if I remember correctly. Fair enough. I did say "some of the best debuggers I've used". I've never used Common Lisp. I have no idea what the debugging experience is like on it. Incidentally, I don't find edit & continue to be a terribly useful feature. >I'm not even sure they've caught up on class redefinition and instance upgrade at runtime yet, which has been supported in CL since the 1980s. That has nothing to do with the tooling, though. C++ just doesn't support those features. You also say "caught up" as if committee members had been trying to add those features to C++ but just hadn't been able to. It's much more likely that there hasn't been enough (or any) interest to add them.
- jhgb 5y ago
  > That has nothing to do with the tooling, though. C++ just doesn't support those features. In principle I don't see how language definition not supporting this would make this entirely impossible. It's just not possible to ask for such a running program transition to be requested from within the language, but with some modest restrictions on program behavior this might be possible to request from within the IDE. The restrictions I imagine to be similar to the restrictions that would enable C++ code to be subject to code-agnostic tracing GC, such as no user-defined XOR-linked lists.
- pjmlp 5y ago
  Energize C++, not surprisingly out of Common Lisp shop. Visual Age for C++ v4, a Smalltalk like experience. Live++ used by Unreal. Edit-and-Continue has been replaced by hot reload on VS.

by jhgb 5y ago

astrange 5y ago

Apple platforms used to have that ("zero-link") and removed it quickly because nobody actually liked it. I think this and Lisp/Smalltalk's image model is actually mistaken. It goes against the principle of "crash-only recovery" to try to recover from a bad state instead of being able to start over from the beginning.

jhgb 5y ago
Generally in CL you should be able to recover from a usable intermediate state and restart from there.
- astrange 5y ago
  That encourages you to live off the intermediate image forever (like autogenerating code and then not maintaining the source for it), but if you miss some data corruption then you're stuck with it.
  - jhgb 5y ago
    You already are autogenerating code in Lisp (using macros), but not without keeping the source for it, which still lives in the source files. If those files are not loadable into a clean image, you're doing something wrong (like CMUCL people find out a long time ago).

fluoridation 5y ago

>Common Lisp implementations allowed you to change your program's code while debugging decades ago. Microsoft added bare minimum of similar functionality like fifteen years ago or so, if I remember correctly. Fair enough. I did say "some of the best debuggers I've used". I've never used Common Lisp. I have no idea what the debugging experience is like on it. Incidentally, I don't find edit & continue to be a terribly useful feature. >I'm not even sure they've caught up on class redefinition and instance upgrade at runtime yet, which has been supported in CL since the 1980s. That has nothing to do with the tooling, though. C++ just doesn't support those features. You also say "caught up" as if committee members had been trying to add those features to C++ but just hadn't been able to. It's much more likely that there hasn't been enough (or any) interest to add them.

jhgb 5y ago
> That has nothing to do with the tooling, though. C++ just doesn't support those features. In principle I don't see how language definition not supporting this would make this entirely impossible. It's just not possible to ask for such a running program transition to be requested from within the language, but with some modest restrictions on program behavior this might be possible to request from within the IDE. The restrictions I imagine to be similar to the restrictions that would enable C++ code to be subject to code-agnostic tracing GC, such as no user-defined XOR-linked lists.
pjmlp 5y ago
Energize C++, not surprisingly out of Common Lisp shop. Visual Age for C++ v4, a Smalltalk like experience. Live++ used by Unreal. Edit-and-Continue has been replaced by hot reload on VS.