3 ms·

Maybe not of commercial value. But I took the time to get SLIME set up, with SBCL, and it seems like a completely different world. I’ve used languages with dyn

Maybe not of commercial value. But I took the time to get SLIME set up, with SBCL, and it seems like a completely different world. I’ve used languages with dynamic loading and REPLs before, and it seems like we still have something to learn from Lisp. Like, the experience is far from ideal—Lisp has its own problems. But it is just so damn nice to redefine a function in a running system, without having to then get the system back into the state that I need. I’ve used IDEs with dynamic code patching, and I’ve used Python systems that reload modules, but there have always been problems with the ergonomics.

NavinF 3y ago
Never understood this sentiment. I was editing functions without restarting the whole program using visual studio >15 years go and the ergonomics were great: I just click the line number next to the function, edit what I need to edit, and click continue to use the new function. https://learn.microsoft.com/en-us/visualstudio/debugger/edit-and-continue?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/edit...
- dietrichepp 3y ago
  I’ve used that before, but the Lisp stuff still feels a lot better. I’m not just running a program and swapping out a function, but I’m using a REPL, some powerful introspection capabilities, a compiler, and a running system all together in a way that just works really nicely. I can add new files, import new libraries, and redefine structures. Objects that I print out in the REPL can be copied out and pasted directly into code. Rather than running the program and fixing the problems, you keep the system running the entire time you’re working on it. And the condition system provides a lot of help when you screw something up. To be clear—I’m not making the argument that people should be writing programs in Lisp. Just that there are some things to learn from the way Lisp development works. In the past, when I’ve used the various edit-and-continue tools, it felt it was just cutting some time out of the edit-compile-run cycle. The Lisp system feels more like a workbench, where you create fixtures to try things out while you are building the system.
  - riffraff 3y ago
    Have you tried a smalltalk environment? There's plenty of mature options both commercial and free, and to me, many years ago,they have a similar feeling.
- kazinator 3y ago
  Program Edit and Continue is a fragile self modifying C code hack that you would never dare try in production on a customer machine. It doesn't simply replace a function binding; it actually replaces code and puts the instruction pointer of existing threads that were running that code into some similar location in the new code. (Which is pretty amazing, to be sure). What's going on in Lisp code reloading is something a lot pedestrian; just new functions are replacing old ones. Thread which are in the middle of running the old functions continue with those ones. When the last thread is done executing a function, it can be garbage collected.
  - pjmlp 3y ago
    It used to be like that, however the new hot code reload uses an improved approach, althought it still isn't Lisp/Smalltalk.
  - Thiez 3y ago
    Editing code live in production should not be part of your workflow, so kind of a pointless feature. I don't work with life-critical software and yet auditors demand that every code-change to production is peer reviewed and linked to a jira item.
    - dietrichepp 3y ago
      To be clear, I’m not describing “editing live in production” as the workflow. The workflow is editing code live on your development machine, committing the changes, and going through the normal code review + CI/CD pipeline you’d set up for any other project. Something like Fix & Continue in Visual Studio is good for testing out smaller changes. By comparison, something like SLIME + Lisp is powerful enough to use for developing new features. The running system on your developer workstation is mostly synchronized with the source code on disk because the interface you use for making changes is the editor. This synchronization is not perfect, but that’s why you have your unit tests and CI/CD pipeline.
    - kazinator 3y ago
      Ticketed and peer-reviewed fixes can be deployed live in production as if they were live code edits. Technically it is the same thing; it's just a process difference.

NavinF 3y ago

Never understood this sentiment. I was editing functions without restarting the whole program using visual studio >15 years go and the ergonomics were great: I just click the line number next to the function, edit what I need to edit, and click continue to use the new function. https://learn.microsoft.com/en-us/visualstudio/debugger/edit-and-continue?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/edit...

dietrichepp 3y ago
I’ve used that before, but the Lisp stuff still feels a lot better. I’m not just running a program and swapping out a function, but I’m using a REPL, some powerful introspection capabilities, a compiler, and a running system all together in a way that just works really nicely. I can add new files, import new libraries, and redefine structures. Objects that I print out in the REPL can be copied out and pasted directly into code. Rather than running the program and fixing the problems, you keep the system running the entire time you’re working on it. And the condition system provides a lot of help when you screw something up. To be clear—I’m not making the argument that people should be writing programs in Lisp. Just that there are some things to learn from the way Lisp development works. In the past, when I’ve used the various edit-and-continue tools, it felt it was just cutting some time out of the edit-compile-run cycle. The Lisp system feels more like a workbench, where you create fixtures to try things out while you are building the system.
- riffraff 3y ago
  Have you tried a smalltalk environment? There's plenty of mature options both commercial and free, and to me, many years ago,they have a similar feeling.
kazinator 3y ago
Program Edit and Continue is a fragile self modifying C code hack that you would never dare try in production on a customer machine. It doesn't simply replace a function binding; it actually replaces code and puts the instruction pointer of existing threads that were running that code into some similar location in the new code. (Which is pretty amazing, to be sure). What's going on in Lisp code reloading is something a lot pedestrian; just new functions are replacing old ones. Thread which are in the middle of running the old functions continue with those ones. When the last thread is done executing a function, it can be garbage collected.
- pjmlp 3y ago
  It used to be like that, however the new hot code reload uses an improved approach, althought it still isn't Lisp/Smalltalk.
- Thiez 3y ago
  Editing code live in production should not be part of your workflow, so kind of a pointless feature. I don't work with life-critical software and yet auditors demand that every code-change to production is peer reviewed and linked to a jira item.
  - dietrichepp 3y ago
    To be clear, I’m not describing “editing live in production” as the workflow. The workflow is editing code live on your development machine, committing the changes, and going through the normal code review + CI/CD pipeline you’d set up for any other project. Something like Fix & Continue in Visual Studio is good for testing out smaller changes. By comparison, something like SLIME + Lisp is powerful enough to use for developing new features. The running system on your developer workstation is mostly synchronized with the source code on disk because the interface you use for making changes is the editor. This synchronization is not perfect, but that’s why you have your unit tests and CI/CD pipeline.
  - kazinator 3y ago
    Ticketed and peer-reviewed fixes can be deployed live in production as if they were live code edits. Technically it is the same thing; it's just a process difference.