Hacker News Reader

Comment by darkwi11ow | Hacker News Reader

You can do this in many other interpreted languages like Python interpreter when running with --pdb flag will do the same. I imagine CL does this by default when running code in interpreted mode and omits the behaviour for compiled (production) binaries.

View on HN

In CL, this works with compiled code.

In Python, can you fix the buggy function, re-compile it, and resume execution from the stack you want? I don't think so. That's common practice in CL, useful both during development and in production if necessary. In Python, you edit the file, your webserver restarts and reloads everything. In CL, the change is in. Nothing is restarted. The function was compiled and the next call will use it.

Python REPL and CL's are very different!

In CL: you can install new dependencies from the REPL. You can change a class definition, the existing objects will take the changes at the next invocation. You can control how this happens, etc. TLDR; CL is built around live programs. Buuut we can also do it the dumb (and safe) way following the industry's best practices.

While this can be useful in extreme situations, such as a production system that can't be taken offline even momentarily, it has always felt like a footgun to me: a way to make critical changes that are recorded nowhere and flow through no change process. Lisps are full of these really powerful features that should be used sparingly, but are held up as reasons to use it. I wrote a fair amount of CL a couple decades ago, but always felt that "pause, inspect, stop, edit, start" was safer than "pause, inspect, edit, restart". Some corollary of Kernighan's Law, there.

You can use the features as little and as safely as you want:

> can be useful in extreme situations

it's already useful in development, it's one of those things that shorten the dev loop and make development in CL a breeze. For production, you choose. Connect to the live image to inspect the state without modifying anything or debug while it's live.

> recorded nowhere

you can connect to a running program and have the source under VCS. The thing to do isn't to copy-paste new function definitions in the live image's REPL, but to connect to the image, make changes to the source files, and re-compile them (a C-c C-c in Slime) (sending changes to the running program).

> safer

yep, some things are safer. Advanced features are useful even for simple things (introspection, etc).

But every language lets you do this in development. Doing it in prod and hot reloading is Common Lisp's special feature.

re: “”In Python, can you fix the buggy function, re-compile it, and resume execution from the stack you want?””

Yes. I code Python in Emacs with the ancient Python support for running a REPL, loading buffers, editing a function and just hot reloading the modified function, etc.

I am an old man, and I like old man tools :-)

mmh but the rest of my examples, you can't do them in Python (:

Yeah but what happens to your server then? The connection it was handling times out I guess, then is the rest of it frozen or what?

no, the app isn't frozen (thinking about the Hunchentoot web server).

Also of course the default is to not get the debugger but let the server thread crash and print the backtrace. With a user setting, you can choose to get the debugger, and have this request wait (the connection may time out, which isn't an issue during development). Another setting is to print the backtrace in the browser (= dev mode).

I mean, that entirely depends on the server design. Is it running one connection per process? One connection per thread? Presumably you've designed the server in a way that one slow connection doesn't block other connections from being handled fast, which means that this one connection whose handler went into the debugger is just now a really, really slow connection taking minutes (or hours!) to handle, but the other connections are running just fine.

Now, if your entire server is taken down because one connection threw an exception, that's bad design. But pretty much no major language works that way. All of them allow you to set things up so that an exception handling connection A won't affect connection B. And if you've done that in Common Lisp, then connection A halting and waiting for the debugger won't affect connection B either.

Maybe beside the point, but I'd hope it's neither connection per process or per thread. Modern webservers tend to rely on either an event loop or greenthreading. Looks like such a thing exists in Common Lisp, not sure how the debugger would interact with it though.

Anyway it sounds like this isn't really the target use case for the debugger since restarting a webserver is supposed to be easy. Maybe there's a different use case in mind?

Reply on news.ycombinator.com