Restarts allow composable bridging, across components, of the interactive and batch/"server" worlds, because they can also be invoked programmatically. Of cours

Restarts allow composable bridging, across components, of the interactive and batch/"server" worlds, because they can also be invoked programmatically. Of course you wouldn't want the debugger popping in your headless server app, but it could be an incredibly powerful option when you turn it on to debug a specific issue. I don't have any first hand experience in this (never doing any server side work in CL) but Paul Graham had mentioned briefly, somewhere, about ye olde Viaweb and being able to interactively debug and fix customer issues on a live system in real time. It's an appealing proposition, though I think he romanticizes it a bit. I agree that function-level recompilation of definitions feels alarmingly undisciplined, borderline irresponsible in a production context. On the other hand, in my $work, I can recall sufficient instances where being able to compile in just a little extra targeted debug logging to a running process would've turned completely baffling production issues into something easily explained, sparing a lot of time and hard thinking trying to infer via code review the root cause of issues that no one was able to reproduce internally, and provide much greater confidence of fixes. It's worth mentioning that on the Lisp machines, the debugger was a first class component of the user interface in a way that might feel very foreign to people accustomed to the Unix command line. It was just a way of inspecting backtraces, it was a essentially a form of interaction where the application could present a problem situation and offer the choices how to proceed.