HN

Comments (120)

• Menu

  vindarel
  The real "[Common] Lisp curse" is that once you taste it, there's no going back.Other than that, the Common Lisp ecosystem is doing well thank you very much. Many contributors to SBCL, regular contributions to the important ecosystem libraries, vivid projects (Lem), new editors (mine) and plugins (OLIVE), some companies picking Lisp and somehow supporting the ecosystem (hosting conferences, contracting implementors). https://github.com/CodyReichert/awesome-cl/ · https://github.com/azzamsa/awesome-lisp-companies/ And yes, new vibe-coded projects too. Some are useful (ICL, cl-tuition…), some reinventing the wheel (badly) went nowhere. For some, we'll see.
• Menu

  jedberg
  This is absolutely correct. I recently found myself asking my agent to modify a local copy of an open source project to fix bugs that I found. It fixed the bugs, and it rebases against the public repo on occasion.Why haven't I submitted my patches? Because my agent wrote them and I didn't review them. I would feel bad submitting my patches without looking at them, and I don't have time to look at them.
• Menu

  gavinray
  I wrote this same concern in February: what happens when it's easier to build custom software than spend one search looking for mature libraries?https://gavinray97.github.io/blog/llm-build-cheaper-than-sea...
• Menu

  jdormit
  > 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.I 100% disagree with this. Supply chain attacks are already at an all-time high due to agentic hacking assistance, and that trend shows no sign of slowing. Every dependency you add is another potential attack vector, and just checking the dependency’s code doesn’t solve the issue - your dependencies also have dependencies!The cost of rolling your own has gotten so low that it’s almost always a better security tradeoff to reimplement the thing yourself. Is that a good thing? I’m not sure.
• fierycatnet
  I'm not a SE but I dabble with code. Lisp was really something else and I really liked it when I was reading SICP. Then I tried Clojure and things just clicked and it was fun to write.
• Menu

  lq9AJ8yrfs
  Decades ago a relative showed me his Amiga. Before putting in the disk (these were on 3.5 inch floppies iirc) with the game I wanted to play on it, he put in another disk.I asked him with the first disk was, and I remember distinctly he said it was an operating system. I asked him what an operating system was, and he said it was like a program, it was a program technically, that makes it easier to run other programs, just it was a program that didn't do much on its own and you wouldn't use it without another program right afterward. I said it didn't seem easier if you had to load a different disk than the one you wanted to use, and you still had to load the one you wanted afterward. He looked at me disdainfully and patiently explained that all or almost all the software in the future would use operating systems and they whole process would get easier or even invisible but there would always be an operating system in there somewhere at some point in the very near future. I was skeptical, but I nodded along.I imagined an operating system as a dressed up software library, which was more intuitive to me as a concept.
• spapas82
  Actually this is not a curse but a blessing! Being able to implement any functionality without the need to resort to dependencies is a godsend.Yes, some dependencies are great. But unfortunately the vast majority are problematic: Not properly supported, badly tested, with unhelpful maintainers, funny licenses, undocumented and, definitely, not being able to cover your requirements 100% so you have to change your requirements to meet the dependencies instead of the other way around.
• Menu

  gleenn
  Seems a bit hyperbolic to call it a curse. Things like these are on a spectrum for all languages and languages like C and many others are afflicted by ecosystems that are more or less community driven and leverage libraries to a greater or lesser extent. Doesn't really have to do with Lisps per se.
• cestith
  This "curse" is not unique to Lisp. There's an old saying something of the sort that for the first week after you install a Forth you have the same Forth as everybody else. After that, you have your own Forth dialect.Any language that's powerful for creating new syntax and doesn't have an equally powerful community repository gets this same effect to some extent.
• Menu

  doug_durham
  So every Lisp developer creates their own time libraries and HTML DOM libraries because it's so easy? No. This is a myth.
• Menu

  GMoromisato
  I've been reinventing the wheel since I started programming. Back then, we had no choice--there weren't any open-source libraries. But I also enjoy reinventing the wheel because (a) the wheel can be exactly how I want it, and (b) I get to learn and understand new things.Coding agents have actually cut both ways for me. I can reinvent the wheel more easily and with higher quality, but I can also integrate an external library much more easily than before.The other day I needed my system to download SFTP, so I had the agent build an SFTP client. It turned out that I actually needed FTPS, so I had the agent build that too.Another time I wanted to integrate with Git repos, but instead of trying to reinvent that, I asked the agent to integrate libgit2. Of course, I asked it to add an API that matched the semantics of my system, so from my perspective, the wheel was exactly how I wanted it.I think what's going to happen is that there will be more vertically integrated platforms that do it all. If you think about it, it's really annoying to cobble together a system from different libraries, each of which might have different semantics.What we want, as developers, is to have a single, well-designed, integrated platform that exposes all the functionality we need in a consistent way. That's a lot easier now that LLMs can mold code to your exact specifications.I'm biased, of course, because that's exactly what I'm building with GridWhale.
• Menu

  baq
  the irony is the repl way of working is extremely well suited for agentic workflows. rust is nice, but lisp is hiding in plain sight
• Menu

  pfdietz
  So this means it's a new dawn for Common Lisp, right? :)
• i_s
  I think there is some truth to this. But it may just be that the threshold for viable open-source collaborative projects increased by an order of magnitude or two. E.g., today if you make a cool datetime library, nobody will care, they can recreate the parts they need in 5 minutes. If you make something much harder to reproduce, then maybe they will. So I just file this under “you need to be more ambitious.”
• Menu

  sobiolite
  I do think the current ecosystem of open-source libraries won't survive as it is, as AI screws up the incentives too much. But agents recreating the wheel for every project isn't practical either.What I think we'll see happen is that AI vendors will create private ecosystems for sharing code. I.e. you subscribe to Codex and you get access to a suite of libraries that speed up your development process. Behind the scenes there'll be a mirror of the how the current ecosystem works, with agents submitting bugs and feature requests and a private swarm of agents working the most popular / high priority.
• athrowaway3z
  If you want to talk about this, steel-man the opposition's argument.
• Menu

  zero_shift
  LLMs stop me using open source libraries for two reasons(1) GitHub is now full of slop. The majority of new open source libraries are now generated by AI. Many come from students who are just looking for resume garnish. Others come from devs who are more excited about being an "open source developer" than actually doing open source development(2) With AI I can probably build something better. And if it's crap? No problem! I can just wait 6 months and rewrite it with gpt_galaxy or Claude Torah or somethingAt the same time I have no real incentives to contribute back. Anything I create competes immediately with a sea of slop. Any actual work I do gets identified and swallowed up by the plagiarism machine. And to be honest I only occasionally had good experiences with OSS anywayI think we are looking at the end of open source software. Not the end of free software - in fact that may end up flourishing with LLMs and reverse engineering and the like. But the idea of programmers sharing code, for communal interest and career building, is completely dead.
• dsign
  Why create a simple piece of code that does exactly what you want, when an LLM can smash libraries and frameworks together as well as anybody else? I can tell because I'm doing it right now. I'm not happy with the resulting bloat, but there's no denying that you can have the worst of both worlds if you really wanna.
• Menu

  firethief
  > if we accept the assumption that it is easier to let an LLM generate functionality than to learn the interfaces of existing libraries and frameworks (or let the LLM integrate these libraries or frameworks)This parenthetical seems like the weakness in the argument to me. Why have an LLM reinvent the wheel rather than let the LLM build on existing libraries?
• Menu

  weinzierl
  Carmack once said something along the lines of him not reusing code a lot but rather rewriting it each time.He is probably not alone, so this "curse" is has never restricted to Lisp completely. There always have been some wood and metal workers besides the many LEGO engineers.
• teddyh
  Called it six months ago: <https://news.ycombinator.com/item?id=47971707>
• layer8
  The possible upside is that it might lead to slower but more focused, thoughtful development of libraries by those who deeply care about it.
• TurboHaskal
  Well, if this means I will get to write code again, even indirectly with LLMs, instead of spending my whole workday merging renovate/dependabot pull requests, then I am all for it.
• smitty1e
  > As a second effect, the creation of new Open Source libraries would stagnate.The very nature of training an LLM seems backward-looking.Or, as a question: has an AI gotten around to generating the Final, One True Programming Language (FOTPL) yet?
• jonahbenton
  (March 2026)lol but still true
• measurablefunc
  Application developers don't worry about binaries produced by compilers & in due time the same will be true for code produced by coding agents. I personally do not care what the code looks like as long as it actually has the features that I want & is secure enough for my limited use cases.
• joe_the_user
  It seems like there are advantages as well as problems to this situation. Notably it prevents "monoculture" in software which prevent global worms. If every website implements network protocols from scratch, it would have bugs but possibly not the same bugs and vulnerabilities as it's neighbor. The extreme is every app is its own OS - back to CP/M where running a program involved inserting a disk and turning on the machine, that "interface" had it's charm.
• phyzix5761
  The original wheel was reinvented continuously across different cultures and eras in history.
• Menu

  d-us-vb
  This is rather interesting. But it misses the point somewhat.The problem is whether or not we want to view code as a medium of communication between other humans vs code as an abstract machine that solves a problem. We know that "programs" in the general sense are fairly objective entities that can be studied objectively, which is where the famous Sussman line about this comes from.But as a language for expressing execution semantics that a machine can then execute to produce a desirable effect on the real world (a solution to a problem), we would not expect such code to be written with other humans in mind, and as lisp is a strictly more expressive language (both for expressing the meaning of an algorithm that other humans will be able to study and understand and that a machine can execute), and that more people who program are concerned with producing a solution to a problem, the "curse of lisp" is the logical conclusion.But it's overblown. There exist many excellent and fairly complete libraries for Lisp: Closer MOP, UIOP, ASDF, Bordeaux Threads, etc. And no surprise, these libraries are virtually ubiquitous and considered (at least by me) to be more or less extensions to the language. And these libraries are written in a fairly readable style that anyone can go and try to understand the code.Secondly, the curse isn't really much of a curse at all. It is more likely to yield more robust programs. The assumption that code reuse through libraries increases software quality doesn't really hold up in practice: libraries that are "complete" tend to add bloat to applications; managing different versions of libraries on the same platform leads to arguments about static vs. dynamic linking, and so on and so forth. Ever had to debug .so versioning bugs on Linux? It's not fun. And yet, that is par for the course if you try to persist in the notion that "libraries and code reuse is always better than reinventing the wheel".As a reaction to the utter failures that have occurred due to following that ideology, entire programming communities have popped up to fight it, particularly the "Handmade Hero" that became Better Software Conferences as well as "Software Should Work". And while those people aren't a huge fan of Lisp, they really do embody the Lisp mindset of "don't be afraid of building your own system in your own solution's language". And this does usually yield nicer systems to work with because programming is theory building: bringing in different ready-made libraries introduces conflicting theories that requires even more glue code to rectify and the glue code rarely foresees all the discrepancies. And so bugs appear in the integrations between them.That's not to say that increasing "the curse of lisp" always yields higher quality. The kinds of developers that make great software with that mindset are the ones that are allergic to inconsistency at any level and so squash bugs as quickly as possible and that is what leads their software to be better. But on the practical side of programming work, you feel a lot less inhibited in trying to fix bugs when you're certain you understand the code and how the implementor decided to map the problem domain onto the range of possible solutions. This is where the issue with LLMs comes in: if programming is theory building (which I firmly believe), then what we're really after with using LLMs to generate code is a more effective technique of translating high level theory of the problem into the low level code that executes to solve the problem. As such, maybe vibe coding can work if the vibe coder diligently keeps in their mind what they're after. But usually what that means is writing notes about the desirable properties of the resultant application. And then they're just back to theory building... just at a somewhat higher level.
• esafak
  This is fragmentation. The advent of slop has caused many repos to stop accepting contributions, and people maintaining their own forks. I do it too, diligently maintaining repos that the original maintainers were unwilling to, or simply to add my desired features.Since code is now cheap I think it is not the end of the world, but it does suck a bit for users, who may need to cobble together multiple forks.
• znpy
  I see two main issues with the point op is trying to make.1. The lisp curse is very lisp-specific because there are so many lisp implementations. But you essentially only have one major rust/ruby/php/java/perl/erlang implementation. Languages like C/C++ only have two major implementations (gcc,llvm/clang).2. I see so many projects every day where developers pull in gigabytes of software only to use a small number of features. Don’t even get me started on the whole left-pad clown show. Gigabytes of libraries pulled left and right only to use a few megabytes at most.
• cmrdporcupine
  "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.Perhaps potentially what replaces "widely used standard implementation of X in a library/npm/crate form" is an "LLM readable recipe for X along with a formal proof / automated test scenario that I can point my clanker at to get a community proven way of doing this" along with a set of prompts, licensing/credit requirements, etc.
• iLemming
  [dead]