Note exactly the same but worth mentioning for C/C++ programmers out there: gdb can actually function as some sort of "cheap" live environment for C and C++

When stopped at a breakpoint, you can evaluate C/C++ expressions, modify state, call functions, and, with compile code, have GDB compile and execute new C/C++ code in the context of the running process:

   (gdb) set variable state->counter = 42
   (gdb) call recompute_state(state)

   (gdb) compile code
   > printf("counter = %d\n", state->counter);
   > do_something(state);
   > end

That makes for a surprisingly nice "REPL attached to a running C program" experience. You can poke at the heap, change variables, call into the existing code, and inject little bits of new code without restarting the process.

One use case I have fond memories of was implementing different trees structure and adding a print_dot function that printed the tree in .dot format and whenever I call the function from inside gdb, the xdot window would redraw with an updated tree graph.

I know it isn't really the same thing as a Lisp image where the injected code is become persistent but still nice to have

P.S: If you are trying gdb's tui for the first time and your program is still laden with print statements, you can ungarble the screen after a printf output with Ctrl+L or the refresh command