7 ms·

A peculiar workflow of REPL-driven programming environments is that the running program is eventually "saved" by writing the state of the virtual machine to dis

A peculiar workflow of REPL-driven programming environments is that the running program is eventually "saved" by writing the state of the virtual machine to disk. There may be no source code to rebuild from, if the program was built interactively. It has its appeal, but it's kind of a nightmare from a maintainability standpoint.

ratzkewatzke 4y ago
I write Lisp for a living (in a couple of different forms), and I've never seen this. You do occasionally get problems where the state drifts a bit and you end up with order dependencies in files, but everybody I know works on source code and pushes it back and forth to the REPL via their editor.
Jtsummers 4y ago
> There may be no source code to rebuild from, if the program was built interactively. If someone did that, they'd be a fool. Common Lisp and Smalltalk, the quintessential REPL-driven languages, have supported storing and loading source from files since their standards were published, and before then since the standards weren't created out of thin air.
gumby 4y ago
That was true of InterLisp-D and the SmallTalk environments, but not the case of the systems that begat CommonLisp (MACLISP, the lispms, franzlisp, etc). In other words it was a cultural thing, not a property of the languages. And even with the systems for which that was possible it was also possible to start with a fresh band and load code into it.
- mikelevins 4y ago
  Moreover, Smalltalk and Interlisp interactions are recorded in files automatically--the changes file, the sources file, and the working image (which also contains tools--e.g. Interlisp's Masterscope--for keeping track of changes). The notion that you'll lose your work if you use the normal means of interacting with the repl is a misunderstanding of how such systems work.
mikelevins 4y ago
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.
bitwize 4y ago
Most Lispers type into source files and send the changes over to the REPL using e.g., SLIME on Emacs. Rebuilding the image from source is always possible. Even under Smalltalk, which works more like you say, the system tracks and saves source changes. At least that's how it works under Squeak and Pharo. Very few developers would be foolish enough to use a heap image as the source of all truth. I'm sure it happens, just like the place I worked at whose entire web stack was based on a magic DLL no one knew how to compile, happened. Like the magic DLL, it's widely considered a terrible, terrible idea.
- jrvarela56 4y ago
  You end up in OPs situation if you type into the REPL - which you're not supposed to. The workflow is amazing because you write the software in the editor you're used to and have keybindings for interacting with the REPL inside your editor.

ratzkewatzke 4y ago

I write Lisp for a living (in a couple of different forms), and I've never seen this. You do occasionally get problems where the state drifts a bit and you end up with order dependencies in files, but everybody I know works on source code and pushes it back and forth to the REPL via their editor.

Jtsummers 4y ago

> There may be no source code to rebuild from, if the program was built interactively. If someone did that, they'd be a fool. Common Lisp and Smalltalk, the quintessential REPL-driven languages, have supported storing and loading source from files since their standards were published, and before then since the standards weren't created out of thin air.

gumby 4y ago

That was true of InterLisp-D and the SmallTalk environments, but not the case of the systems that begat CommonLisp (MACLISP, the lispms, franzlisp, etc). In other words it was a cultural thing, not a property of the languages. And even with the systems for which that was possible it was also possible to start with a fresh band and load code into it.

mikelevins 4y ago
Moreover, Smalltalk and Interlisp interactions are recorded in files automatically--the changes file, the sources file, and the working image (which also contains tools--e.g. Interlisp's Masterscope--for keeping track of changes). The notion that you'll lose your work if you use the normal means of interacting with the repl is a misunderstanding of how such systems work.

mikelevins 4y ago

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.

bitwize 4y ago

Most Lispers type into source files and send the changes over to the REPL using e.g., SLIME on Emacs. Rebuilding the image from source is always possible. Even under Smalltalk, which works more like you say, the system tracks and saves source changes. At least that's how it works under Squeak and Pharo. Very few developers would be foolish enough to use a heap image as the source of all truth. I'm sure it happens, just like the place I worked at whose entire web stack was based on a magic DLL no one knew how to compile, happened. Like the magic DLL, it's widely considered a terrible, terrible idea.

jrvarela56 4y ago
You end up in OPs situation if you type into the REPL - which you're not supposed to. The workflow is amazing because you write the software in the editor you're used to and have keybindings for interacting with the REPL inside your editor.