> 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.

▲

rootnod3 3 hours ago | parent | next [-]

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.

▲

frollogaston 3 hours ago | parent | prev [-]

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

▲

giancarlostoro 3 hours ago | parent [-]

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.

▲

frollogaston 3 hours ago | parent [-]

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

▲

giancarlostoro 3 hours ago | parent | next [-]

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.

	▲	Capricorn2481 2 hours ago \| parent [-]
		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?

▲

rmunn 3 hours ago | parent | prev | next [-]

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

	▲	3 hours ago \| parent [-]
		[deleted]

▲

anonair 3 hours ago | parent | prev [-]

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

(not a CL expert here)

	▲	frollogaston 13 minutes ago \| parent \| next [-]
		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.
	▲	2 hours ago \| parent \| prev [-]
		[deleted]