On: Why Target Common Lisp for Code Generation?

[mtlmtlmtlmtl → rhet0rica]

I'll never understand why people post LLM outputs in forums pretending they wrote it themselves.

You asked Claude or some other agent to make your argument for you, and what you got was a well formatted pile of nothing. Bravo.

[rhet0rica → mtlmtlmtlmtl]

That is... honestly an insane reaction. I spent half an hour writing that.

I'm sorry you're scared by em-dashes. They were cool when I was young, alright?

[dreamcompiler → rhet0rica]

> Conversely CL's standard library is indebted to decades of history.

There's no such thing as "CL's standard library." I presume you mean the functions built into Common Lisp which provide basic functionality, but nobody uses "bare" Common Lisp any more than anybody uses bare C. The Quicklisp libraries for CL (among others) provide the modern utilities you seem to think CL lacks.

[rhet0rica → dreamcompiler]

I was thinking of the functions as described by the Common Lisp HyperSpec. Reading it makes me cry.

It is not unreasonable to call that a 'standard library.' The term 'standard library' is often used to describe built-ins.

The age of the CL core functions is a genuine weakness, specifically in terms of performance. No matter how many libraries you download from Quicklisp, they still have to be implemented in something, and if that something is antiquated or clunky, you're essentially asking the compiler to optimize the entire language out of existence to keep up with the state of the art. The same applies to npm, pip, cargo, and all the rest.