[vindarel]

To really discover what interactive, image-based CL development is about, my pointers:

- https://www.youtube.com/watch?v=jBBS4FeY7XM (5min) my demo to show how to resume execution of a long running program, from the stack frame right before the bug, after having fixed and recompiled the function, without quitting the debugger hence without stopping the program, thus without restarting everything from zero.

- https://www.youtube.com/watch?v=nsKx40ab9SY (20min)showing what saving and restoring an image does, differences between SBCL and LispWorks.

- https://www.youtube.com/watch?v=1aboMZkNDCY developing a 3D graphics software.

- https://mikelevins.github.io/posts/2020-12-18-repl-driven/

- debugging CL tools: https://lispcookbook.github.io/cl-cookbook/debugging.html

- and no: while we could deploy a ball of mud to production, we can also not and use traditional tools and techniques: build an executable from scratch, restart the app, reload state. But we can do everything in between too (inspect the running app, change it a bit, change it a whole lot (while staying in sync with local source code), use images to speed-up development etc).

[pjmlp]

The critic of shipping images in Common Lisp and Smalltalk is kind of ironic in the days of Docker and Kubernetes all over the place.

Thanks for the links.

[whartung]

To a point. There's an entire culture of software and processes around building up container images from scratch for deployment. There's a term of art that I forget, "Pets vs XXX", with XXX being disposable VMs, in contrast to a Pet computer lovingly cared for over time.

For many Common Lisp scenarios, it's actually similar -- start with the raw based image, load in your code and data, snapshot it, and ship the resulting artifact. At least for me, interactive development aside, it's not untoward to restart a CL system from scratch as a routine part of development. We're not running on Lisp Machines anymore where restarting was actually quite expensive (though there were anecdotes about how at some point it was faster to restart a LispM than let it grind through its GC process, I don't know about that).

However, I don't know how common that is with Smalltalk. How often they restart from scratch. Saving the image is routine in Smalltalk. Where in Lisp you CAN save the image, it's not necessarily part and parcel operationally, historically, or culturally to constantly save the image, especially post LispM. In Smalltalk it is.

I think with CL folk moreso build a new base image, load in some routine utilities, etc. to form a baseline. But application code and image are separate.

Smalltalk, they're not. Code is part of the image (it's stored separately, but it's presented as if they're one and the same). So the image is a much more first class citizen in the Smalltalk world, rather than, perhaps, an artifact.

Especially today, I imagine they have build processes that build up the entire thing again from scratch, but it would not surprise me if they bumped into problems where the image and the source code "don't quite match" that they have to suss out in testing before deployment, because something slipped through and tweaked the long saved image that wasn't properly captured.

In any case, while I'm sure it doesn't quite happen like that today, its not unreasonable to have someone ship a "ball of mud" Smalltalk image in contrast to one in CL.

[lispm]

Generally Common Lisp is agnostic to the development style. For production, there are also batch compiler. Image saving/starting is also not supported by all implementations (not supported for example in ECL and ABCL).

In early Lisp I would guess it was more often to save an image. There is one system which works mostly like Smalltalk: Interlisp-D, now called Medley. https://interlisp.org It also manages the code, in some ways similar to Smalltalk. Interlisp was provided by Xerox PARC, like Smalltalk. It originates from BBN Lisp, from the 60s.

Other than that, most Lisp systems store code in the file system.

> its not unreasonable to have someone ship a "ball of mud"

That's also relatively common (!) in Lisp.

In Smalltalk we often see variants which can ship images and run them on different architectures. In Common Lisp images are mostly tied to a certain architecture & OS.

[everforward]

> There's a term of art that I forget, "Pets vs XXX", with XXX being disposable VMs, in contrast to a Pet computer lovingly cared for over time.

"Cattle" is what I usually hear. Pets are unique and cannot be interchanged. Cattle are fungible and expendable.

[yourapostasy]

> But we can do everything in between too (inspect the running app, change it a bit, change it a whole lot (while staying in sync with local source code), use images to speed-up development etc).

Is anyone aware of SBCL or LispWorks-based tooling that integrates with ServiceNow CHG records to record and perform these kinds of changes to automatically create an audit trail of such changes in a CHG record as the Lisp image is manipulated for emergency changes?