AFAIK both Lisp and Smalltalk environments are image based. That is, all source code and all objects are stored in memory. You need to save that image in order to continue from where you left off. Snapshots are also used to allow rollback to previous "good" states.
> That is, all source code and all objects are stored in memory.
Common Lisp usually stores code in form of normal source files that are then possible to load into a clean-slate Lisp image. It's possible to dump images and restore them, but it's not the norm of working with CL.
Unlike in Smalltalk, I currently know of no tools that allow one to easily edit source code of functions/methods that have already been compiled into the system, and therefore the dependency on the filesystem source files is heavy and immediate.
AFAIK dumping images in CL is mostly used for shortening load times by preloading code and data, and for application delivery, but not for live editing support.
> Unlike in Smalltalk, I currently know of no tools that allow one to easily edit source code of functions/methods that have already been compiled into the system
Lots of Common Lisp systems support that in some way. Those record the location of the source code together with the machine code. These locations are stored in the image.
For example the standard CL function ED takes a function name and in many Lisp systems this will edit the function in some implementation specific way. In Emacs one uses M-. to get the definition of a function. In those implementation it will ask the Lisp for the location of that function source code.
The one system that worked similar to Smalltalk is Interlisp. See https://interlisp.org . It recently has been open sourced and is in the process of making it more accessible. It's a glimpse into an alternative world of computing from the past.
I know that many implementations record source location, but the source itself is still on the filesystem, not in memory, therefore making source locations useless if we move the filesystem out of the equation.
I also know that many implementations store the forms in FUNCTION-LAMBDA-EXPRESSION, but as I said, I know of no easy way to edit these in-memory forms either. Interlisp has had a structure editor to work with those, but that utility was not ported back into the CL workflow. I hope it eventually will be, with Interlisp being open sourced now.
Just make source available on the file system. Mount it. Copy it.
That's why Common Lisp has logical pathnames. Typically one uses logical pathnames in source locations. When I set up my application on a machine, I define a translation table to point to the source code.
One can also just use standard pathnames and mount the source code to a standard path. That's how one also has set up Lisp systems in clusters. Every machine mounts the source in a standard path (or a logical path) and a client system will then have access to that source code. The image still has the recorded locations.
Btw., even Smalltalk stores its source code not in the image. The Smalltalk source code is stored OUTSIDE of the image in the file system and it has to have the files available and needs to know the location of these source files.
The Squeak/Smalltalk programming system consists of three parts:
* a virtual machine for your platform,
* both image and changes files of a particular version, and
* a sources file for the particular image file.
The source and changes files contain the source code of the running Smalltalk. An edit of source code will then lead to an entry in the changes file.
Smalltalk usually can decompile byte code, so one can edit code which has no corresponding source code, with some loss of original source information.
One can redefine functions on the fly in Common Lisp. One can retain the source associated with compiled functions (even if the Common Lisp doesn't natively support that, by augmenting DEFUN via the macroexpand hook). I have done just this in an in-core mutation testing framework for Common Lisp, which creates and tests hundreds of mutant versions of a function, automatically.
In general though, there's little good reason to edit Common Lisp code in core. Common Lisp is a language with structure at the character level (reader macros); reading in a form loses all this. This is unlike Interlisp, where everything, even comments, were s-exprs and could be edited in memory with sedit.
It's not compiled, but Ruby's Pry REPL allows you to edit and update code files during live execution. I use it all the time for adding breakpoints and live fixing issues. It's very productive for problem solving.
I think the point of the article is that tooling can only get you so far. The abstraction they attempt to provide is leaky if the support for this style of development isn't firmly designed into the entire system.
Yeah, but in that regard developer culture is what matters.
I have seen very few people actually using these kind of workflows back when Smalltalk and Lisp were more relevant (I used Smalltalk/V back then).
It is like using gdb, many don't go beyond step, next, print, run, breakpoint and discover how powerful it actually is (same applies to other debuggers).
I am indeed claiming that tooling only gets you so far, if you don't have good support designed into the runtime.
I take you at your word that you didn't use the sorts of workflows I've described, but I did, and I still do, to the extent that I can, and it was common place among, for example, the programmers working on the bauhaus OS or the ones working on the SK8 development environment.
We kept images around as a matter of course for various purposes, for example.
