Hacker News Reader

Comment by giancarlostoro | Hacker News Reader

> In Common Lisp your program won’t crash, it’ll stop and open a debugger with the whole stack and all the variables. You can just point your LLM at the debugger, and it’ll make its fix and resume the program.

> To my knowledge Common Lisp is the only mainstream language that does all of this.

Sounds like someone who has never used C# and Visual Studio? Even JavaScript is capable of doing this, honestly JavaScript might be the one language with the richest developer tooling of all time (possibly?), sad to say because there's nicer to work with languages out there.

View on HN

I think what is referred to here is that an exception doesn't unwind the stack. Even if the exception is uncaught, you can fix the line or value and then resume where the stack was.

No, it's catching/editing/recompiling/continuing at the point of crash, also you can change the current line and variables so many crashes are "resettable" manually.

Visual Studio has done this since the 90s for C++ code (and C# code for a good while also, just most people have debugger exception catching turned off).

How I know? Back in 2000-2001 we were working on a Dreamcast game with a 3dfx/Glide PC renderer, that 3dfx driver on WinNT was unstable and crashed the machine every 3rd-5th start of the game so being able to edit-continue was a damn lifesaver since a lot of common tweaking of custom stuff outside of what connected to the scripting system could be done at runtime.

This is one thing I think so makes people loyal to MSVC despite it having been behind on standards (gonna be interesting to see if they get reflection up to speed for the 2027 release, GCC's there but not yet Clang).

You continue from where the exception lands, but not from the origin of the expection. The .NET runtime for example does termination handling and it's in the spec if I remember correctly. Common Lisp has a resumption model.

The leave instruction is required to exit a try, catch, or a filter block. At least last time I read the spec (which is a while ago, but still).

See https://news.ycombinator.com/item?id=23844283 for examples on CL.

So you're saying I'm hallucinating while working?

No, the debugger (when using Visual Studio proper) breaks at the point of throwing (be it an explicit throw or something underlying like a NPE or out-of-bounds access), _I_ literally use this _all_ the time to fix code while in motion (set next statement on a line a bit back or even the same line to rewind just a tiny bit, change the code, fix errant variables, press F5 to continue and the IDE will rebuild and reposition instruction pointers and update stacks).

What the spec says about execution semantics of exceptions is one thing, what capabilities the debugger provides can be something entirely different.

Perhaps VSCode or some other environments don't have as good debuggers, but trust me when I say that it allows you do do exactly what you need.

Someone saying something in a comment doesn't negate a capability that person doesn't know about.

https://learn.microsoft.com/en-us/visualstudio/debugger/mana...

I don't see it print the "here" line in their example.

IF you're running a debug build. I guess Common Lisp can do this in prod?

I mean, so can JavaScript then? Why would I want a debugging window to open up for a customer in production? I remember when Windows used to try to open a debugger when certain programs crashed on me as if I knew what the heck any of that was supposed to mean.

Was assuming it was a backend. I still don't understand the advantage though. It'd help to have an example.

Just finished typing up an example as you wrote this. Rather than duplicate it, here's the link:

https://news.ycombinator.com/item?id=49974251

Thing is with .NET you can debug a release build, and even do remote debugging... So it's all a weird claim to me. Definitely someone who only uses Common Lisp and maybe a language with a less impressive debugging background wrote this article.

To be fair, I love Lisp, I dont do a lot with it, though I'm mostly a fan of Racket which is the most modern one outside of maybe Clojure.

Yeah, you don't want a lisp debugging window in production. The absence of stack unwinding does enable editing behavior with wrappers. You could have different error handling without changing any code downstream, and I guess an LLM could theoretically change that depending on the bug it's responding to.

But I'm not positive the juice is worth the squeeze, and this article was unconvincing. I mean if you want macros and terse code and a bigger ecosystem, wouldn't Clojure make more sense?

I imagine production backend with LLM connected using debug interface and patching the code continuously on any exception encounter.

(not a CL expert here)

Erm, sounds niche. Like you can normally do all that minus resuming the program in other languages. If this is a webserver, it should be fine to restart it for an update, it's not like I'm going to catch some user's failed request and patch it before it times out.

Good luck debugging all that minified JS code without a map file. It can be done, but will be very painful.

No debugging window opens up for anybody by default^^ The web server (ex: Hunchentoot) will crash the request's thread and print the backtrace by default. Change a server's variable and print the backtrace in the browser (= dev mode), change another variable and get the interactive debugger (= dev mode++). All this without stopping/restarting the server. Or just restart it if you want.

Reply on news.ycombinator.com