3 ms·

No. I've been doing repl-driven development with Common Lisp compilers for about 33 years now. I have never ever worked in the way that you describe, and have

No. I've been doing repl-driven development with Common Lisp compilers for about 33 years now. I have never ever worked in the way that you describe, and have never witnessed anyone else working that way, either. It would be a nightmare for maintainability if anyone worked that way, but if they do, I haven't ever seen it. I do write the state of the runtime to image files from time to time for various purposes. I assure you, though, that all the code I write lives in files that are maintained under revision control, and it's been that way for many years, and in all that time I've never been in danger of losing any work because of forgetting to write an image file.

PaulDavisThe1st 4y ago
To be fair, this general idea was at the core of how many versions of (at least GNU) emacs were created: launch minimal version, load lots of stuff, dump. Fire up dump in the future. Nevertheless, this still does not add up to precisely what the GP described.
- froh 4y ago
  That's not for developing emacs, but for accelerating emacs startup. Smalltalk in contrast has GP's model of saving and reloading the VM state.
  - mikelevins 4y ago
    Most Smalltalk systems and most Common Lisp systems and Interlisp and Factor, and, for that matter, some Schemes and the version of Dylan that Apple used to develop the bauhaus OS, all offer the convenience of starting up from a saved image and of saving a new image to preserve incremental changes for next time. Interlisp and most Smalltalk systems also offer the convenience of automatic change tracking, writing your changes to the sources file and the changes file, and providing in-image tools for browsing and managing changes, including things like Interlisp’s Masterscope and Pharo and Squeak’s Monticello. These tools make life more convenient for people who prefer to work mainly with the in-image tools and not to mess with text files that much. But if there’s a Smalltalk system that relies solely on the image file to preserve changes, with no support for other means of change tracking, I’m not aware of it.
pixelrevision 4y ago
I’ve always been curious about this. If you are not writing out the state of the program is there some convenient way to output parts of it? The article describes adding functions and refactoring data types but if you are doing that I’d assume you’d want those changes back in your source files.
- rvense 4y ago
  The REPL and editor are connected. You have a key command in your editor that sends the form you want to evaluate to the REPL, which is in a separate window or pane.
  - medo-bear 4y ago
    when i write cl that is precisely what i do. i imagine this is the case with everyone - ie write code into the source file and send new bits to the repl
  - mikelevins 4y ago
    Right, except that the repl isn't in another pane; a repl prompt is. Part of the confusion on this point is thinking that the prompt is the repl. It isn't. It's a UI for the repl. The repl is the process that reads, evaluates, and prints, then loops back to do it again. Nothing about a repl requires there to be a prompt, and not all UIs for repls have them. Interlisp and Smalltalk have relied mainly on promptless UIs for their repls since the 1970s. When working with Common Lisp, the main UI I use is an Emacs editor buffer and the key bindings that send input directly to the repl (bypassing the prompt). Typing at the prompt is the exception rather than the rule, and I could get along fine if I didn't bother to load the slime-repl contrib that provides it.
    - xkriva11 4y ago
      Yes, the evaluation of the code needs to be possible from everywhere. From the REPL window, the code editor, the debugger, and the inspector... Any code you select should be possible to evaluate in place. It is more than four decades old obvious basic idea, and I do not understand why almost everybody ignores it.

PaulDavisThe1st 4y ago

To be fair, this general idea was at the core of how many versions of (at least GNU) emacs were created: launch minimal version, load lots of stuff, dump. Fire up dump in the future. Nevertheless, this still does not add up to precisely what the GP described.

froh 4y ago
That's not for developing emacs, but for accelerating emacs startup. Smalltalk in contrast has GP's model of saving and reloading the VM state.
- mikelevins 4y ago
  Most Smalltalk systems and most Common Lisp systems and Interlisp and Factor, and, for that matter, some Schemes and the version of Dylan that Apple used to develop the bauhaus OS, all offer the convenience of starting up from a saved image and of saving a new image to preserve incremental changes for next time. Interlisp and most Smalltalk systems also offer the convenience of automatic change tracking, writing your changes to the sources file and the changes file, and providing in-image tools for browsing and managing changes, including things like Interlisp’s Masterscope and Pharo and Squeak’s Monticello. These tools make life more convenient for people who prefer to work mainly with the in-image tools and not to mess with text files that much. But if there’s a Smalltalk system that relies solely on the image file to preserve changes, with no support for other means of change tracking, I’m not aware of it.

pixelrevision 4y ago

I’ve always been curious about this. If you are not writing out the state of the program is there some convenient way to output parts of it? The article describes adding functions and refactoring data types but if you are doing that I’d assume you’d want those changes back in your source files.

rvense 4y ago
The REPL and editor are connected. You have a key command in your editor that sends the form you want to evaluate to the REPL, which is in a separate window or pane.
- medo-bear 4y ago
  when i write cl that is precisely what i do. i imagine this is the case with everyone - ie write code into the source file and send new bits to the repl
- mikelevins 4y ago
  Right, except that the repl isn't in another pane; a repl prompt is. Part of the confusion on this point is thinking that the prompt is the repl. It isn't. It's a UI for the repl. The repl is the process that reads, evaluates, and prints, then loops back to do it again. Nothing about a repl requires there to be a prompt, and not all UIs for repls have them. Interlisp and Smalltalk have relied mainly on promptless UIs for their repls since the 1970s. When working with Common Lisp, the main UI I use is an Emacs editor buffer and the key bindings that send input directly to the repl (bypassing the prompt). Typing at the prompt is the exception rather than the rule, and I could get along fine if I didn't bother to load the slime-repl contrib that provides it.
  - xkriva11 4y ago
    Yes, the evaluation of the code needs to be possible from everywhere. From the REPL window, the code editor, the debugger, and the inspector... Any code you select should be possible to evaluate in place. It is more than four decades old obvious basic idea, and I do not understand why almost everybody ignores it.