A curmudgeon tries a language server

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.

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

Gawd, that image-based approach to programming has never been mainstream because it creates a terrible mess. Look at the nightmare notebooks you get from data scientists working in Python where they want to have their answers baked into a notebook that they can show to people and don't realize they need to separate code and data in version control and have a script you can run from top to bottom every single time if they want to put their skills on wheels.

i have learned a lot of interesting facts about haskell and lisp from this post. those facts make me want to run screaming away from trying to use either of them to develop software. My time with Haskell made me a better programmer and I bet that LLMs made some of the documentation more intelligible, but...

To be honest given the amount of structural obliteration you get out of GHC, image-based development sounds like a really bad idea. Haskell is such a weird and unintuitive language to understand from a systems perspective, because it's almost like you're restricted to writing macros for a language that you never directly see or interact with. The transformation from your source code to what the compiler spits out is can be highly non-local and unpredictable, even before you start introducing things like custom rewrite rules. To me, I think the smart way to work with Haskell is the exact opposite of iteration. Work it out on paper, refine it, find the algebraic rules for it, refine it some more, and then start writing code once you know exactly what you're doing. I think giving in to the temptation to Just Start Writing Code is how you end up with opaque type spaghetti. That's just my feelings on it.