[arnsholt]

Smalltalk has live update of the running program, arguably in a much better way than (modern) Lisps. In Smalltalk you edit code directly in the running image, there's no possibility of defining a function in the REPL and having a different definition in a source file somewhere: the source is the image, and any change to code is reflected in the image. The old Lisp machine Lisps (like Interlisp) used to do this too, I think, but no CL implementation I know of does this anymore.

The Smalltalk debugger is famously also implemented in the development image (and implementing a simple debugger is a common project in Smalltalk textbooks). Traversing the stack, accessing locals, stepping, etc. are of course all possible.

No CLOS in Smalltalk admittedly, but lots of shenanigans are possible by fiddling with the object model.

Likewise no macros, but Smalltalk syntax is so minimalistic that creating control structures that look like the built-ins is trivial. In fact, conditionals, loops and the like are entirely unmagical in Smalltalk (modulo performance optimizations to make things go fast); reimplementing conditionals (that look and work exactly like the standard set) for example is trivial.

[lispm]

> the source is the image

Actually I thought the sources are stored in a source file and a corresponding changes file. True, one could de-compile the byte code - but usually the Smalltalk editor uses the sources from the sources/changes files.

Smalltalk actually tracks the editing operations / class operations and uses the sources/changes file as a simple code database.

> there's no possibility of defining a function in the REPL

If I programmatically create a class in Smalltalk, is it recorded in the source?

> Traversing the stack, accessing locals, stepping, etc. are of course all possible.

we do that in Lisp, too - the difference is that there is no virtual machine specified and none is common. The default mode of executing Lisp is a) interpreting or by using compiled code (usually to machine code, or to C and then to machine code, ...). There are virtual machines, but they are usually tied to a specific Lisp implementation.

[arnsholt]

The code is obviously stored somewhere, but that's not a user-facing place. Thus, if you define a function in the Smalltalk REPL equivalent (a workspace), when you open that function in the code editor later, you'll see the definition from the REPL, which is the interesting point. There's no way to have one definition on foo in foo.lisp and a different definition actually running in your image because you did a `(defun foo() ...)` from the REPL.

> If I programmatically create a class in Smalltalk, is it recorded in the source?

There's no distinction between programmatically created and other elements. Using the UI to create a class is just a front-end to the metaprogramming facilities you'd use to do it yourself at runtime.

[lispm]

> you'll see the definition from the REPL, which is the interesting point

whose source was put into the changes file

It's managed source code, but the source code is not in the image itself. Smalltalk tracks the connection and creates change records for changes done by meta-programming.

That's for example slightly different with a residential system like Interlisp-D / Medley, where the code is in the image itself, the editor is a structure editor actually editing it and the system can run either the source directly (via the Lisp Interpreter) or a compiled version of it.

But that method is not very popular in the Lisp world, where images are used, but changes are not tracked. Most Lisp development only track location of things. Changing sources is also not connected to quitting an image. It's a separate operation. Lisp also never bought into mostly a single development style/environment like Smalltalk did.