Re:The Lisp curse, now coming to your ecosystem
by cmrdporcupine on Thursday November 05, 2026 @01:46PM
(#50382796)
"I’d rather rely on proven libraries with well-defined abstractions than generate hundreds of lines of code which solve a local problem for me. “Not generated here” is just a different version of “Not invented here”.
I disagree generally, and the problem is two fold..
I've just seen "well-defined" abstractions go wrong too many times. Over- encapsulation, over-abstraction, or just overall over-cleverness in third party packages that has led me to spend large parts of my career just frustrated trying to glue third party dependencies together in a sensible way... and the abstractions only adding complication.
The joy and temptation of having an LLM "just make it" is that this goes away. The functionality fits my existing structure and abstractions and I'm not fighting a war with the architecture that the third party maintainer decided worked best for them. And getting only the parts I need, not your whole giant framework with it. (And yes, I know the LLM could easily hallucinate something far far worse, but let's just... play pretend here for a minute)
The second part is that since the dawn of Maven, NPM, Crates.io generally there has just been this insane explosion in programs of transitive third party dependencies out into the stratosphere, and the cognitive, technical, and legal debt of so many deps generally is not sufficiently recognized by the community. Running "cargo tree" in my project is often frankly depressing. Multiple linked MD5/SHA256 implementations, random number generators, HTTP protocols, people dragging in tokio deps where I don't want them, multiple versions of the same thing compiled and linked... It's exceedingly frustrating, and with the explosion of security concerns we've seen recently, it's also potentially dangerous.
I don't love the idea of having LLMs "just yeet it" esp if people misapply this to things like security/cryptography domains. But I'm also more than skeptical about the actual real world quality of many hallowed third party packages. I've been burned too many times.
I disagree generally, and the problem is two fold..
I've just seen "well-defined" abstractions go wrong too many times. Over- encapsulation, over-abstraction, or just overall over-cleverness in third party packages that has led me to spend large parts of my career just frustrated trying to glue third party dependencies together in a sensible way... and the abstractions only adding complication.
The joy and temptation of having an LLM "just make it" is that this goes away. The functionality fits my existing structure and abstractions and I'm not fighting a war with the architecture that the third party maintainer decided worked best for them. And getting only the parts I need, not your whole giant framework with it. (And yes, I know the LLM could easily hallucinate something far far worse, but let's just... play pretend here for a minute)
The second part is that since the dawn of Maven, NPM, Crates.io generally there has just been this insane explosion in programs of transitive third party dependencies out into the stratosphere, and the cognitive, technical, and legal debt of so many deps generally is not sufficiently recognized by the community. Running "cargo tree" in my project is often frankly depressing. Multiple linked MD5/SHA256 implementations, random number generators, HTTP protocols, people dragging in tokio deps where I don't want them, multiple versions of the same thing compiled and linked... It's exceedingly frustrating, and with the explosion of security concerns we've seen recently, it's also potentially dangerous.
I don't love the idea of having LLMs "just yeet it" esp if people misapply this to things like security/cryptography domains. But I'm also more than skeptical about the actual real world quality of many hallowed third party packages. I've been burned too many times.