> Why do print-line-debugging to find out what's happening at a location in code when you can just be inside your program and inspect everything live as it's running?
Yes, that's because print-effing one's way to understanding is also among the most crude methods of debugging. An excellent alternative to doing that is to use an actual debugger. That will also allow you to be "inside your program".
The difference with lisps is that the debugger is always part of the runtime and you have full access to all the languages capabilities while inside.
I've yet to see a C debugger which does more than a fancy version of printf. Imagine being able to compile functions on the go while still running your main program with all the state saved.
How do you "get inside your program" on a locked down production box? Watched by SOX auditors like hawks? Any answer offered needs to be comparably easy to checking in an extra printf and letting ci/cd deploy it.
I used to be an Erlang engineer, and you would have needed very explicit security controls around being able to attach to an Erlang cluster to get the "insider your program" experience. This was in FinTech, so I'm familiar with the constraint.
I would imagine you'd need the same thing for accessing the runtime of any production deployed application(s) in such an unfettered manner. Erlang, Lisp, C, or other?
Yes, that's because print-effing one's way to understanding is also among the most crude methods of debugging. An excellent alternative to doing that is to use an actual debugger. That will also allow you to be "inside your program".