As a Common Lisp developer, the intro about Lisp strikes me as sort of mostly(?) true.

I would say in my experience we do actually "compile and execute" code, we can just do this incrementally and with less context switching because of the described workflow. But quite often there are in fact separate compile and run steps, it's just not at the whole program level (say, compile a function and run it or a calling function).

And despite how often it's shown off as a strength, redefining code during actual execution isn't quite that common, I think. Yes, it is done sometimes, but lots of programs don't really fit that paradigm in the first place. It can work well for e.g. some games or long running servers.

As for working in an image without source code: this seems like a terrible idea. You might do this for trivial, one off experiments, but in general you benefit from writing out and organizing your code early. I'm not even aware of a particularly easy or clean way to write out source code from an image as described. It could be done, but all the ways I can think of sound like more of a pain or mess than anything. Could just be my experience or I'm missing some neat feature of a commercial Lisp or something.

I haven't used Lisp but I've used another environment that was heavily image based (Frontier). The runtime ability to modify things sounds super neat but in my opinion it leads to disaster. It is not a weakness that we have a lot of tech built on a concrete specification of the initial state of the system and very careful control over where data and the modified versions of that data live. It is hard-won experience that it is a good way to build robust systems. "Reboot & pray" isn't just an accident, it's a legitimately good way to set up a system.

Some of you may object to the idea that we are super careful with data and modifications to it. I know where you are coming from... however, compared to an image-based system, the modern world is in fact super careful! To the extent that you think we are still not careful enough, that leads you even farther from wanting an image-based system.

If you conceive of a system as the full state space of everywhere it can go, the vast, vast, vast majority of systems have pathological places in it. It is very hard to get them all out. It is advantageous to have a button that says "restart this system from the initial state", and to push it often to make sure it continues to work, even if you're not thinking of it this way. By contrast, image-based systems have the tendency to either 1. get into a bad place in the state space and then the user has no way back out or 2. accidentally create a scenario in which there is no way to bring the system up from scratch anymore, which includes things like "giving the system to someone else to start their own work up".

Sure, it's a good idea to minimize the need to hit the reset button. But you don't really want to give it up entirely.

There are a variety of ways of improving the image-based system. Most, perhaps all of the practical ones, involve basically removing the image-based nature of it and moving closer to the systems we all work with today.

I am not a Lisp developer by trade, but I accidentally made an interpreted Lisp as a habitat for LLMs. My research has mirrored exactly what you are saying.

I think conceptually, Lisp was an interpreted runtime. However, the combination of chasing efficiency with compilation and perhaps "everything is a file" consuming mindshare, interpreted Lisp seems a largely academic pursuit.

It's really great for running agents, though.

Even the original MIT Lisp Machine was designed around editing source files, there were "compile the current function" keybindings and menu options in the version of Emacs for it.

You could also type an individual function into the repl then pretty-print it to a file but that typically expands out any read macros that you may have used.

I also found the description of Lisp development weird, as if it's a second-hand repetition of someone else describing watching a Lisp developer in action.

The workflow I always use is to write code in my editor and use a keyboard shortcut to evaluate it. Typing directly into the REPL is for one-off state updates, inspection, experiments, and similar throwaway code.

That intro would make much more sense if you replaced "Lisp" with "Smalltalk".