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.
When worldwideweb.app was first being developed an the RFCs and so forth for web servers and protocols were being discussed, one of the sticking point was what to call a URL --- the initial suggestion was "Universal Resource Locator", but the argument was made that users and writers were not librarians and that the distributed nature would preclude a given web page having a universally agreed-upon location and name, so instead the present "Uniform Resource Locator" was adopted.
What if there was a code sharing site where it was unambiguous what a given snippet of code would be named and where it would be stored, so that a user could just browse it and find a list of implementations for a given problem?
This of course runs up against one what John Ousterhout notes is one of the most difficult problems in computer science --- naming things --- in his book:
I've tried to do it on a small-scale with my own work, storing bits of (la).tex code in a single file, but on reviewing it, I'll often find that I have written a given solution a second time and given the macro a slightly different name....
One positive result is that you get a lot more variation in vulnerabilities. That probably sounds negative, but it isn't.
As an example, a black hat doesn't get 70% of web sites from one shared bug in PHP. They need to target specific sites, and the exploit isn't likely to work in very many other places.
I've been playing around with LLM red teaming different server stacks with known or intentionally vulns in there and seeing how much damage they can do.
The one situation where they really can't get anywhere profitable is a unikernel webapp. With no source and no shell they find the vuln but the worst they can do with it is possibly poison or exfiltrate data as a one off, or crash the server. Often they can't even figure that out. Can't even leave themselves a reliable way back in.
Of course the traditional problem with unikernels is that you have to port EVERYTHING you need yourself. But the cheapness of this is exactly what we're talking about so.
Looks like security through obscurity's back on the menu.
A few years ago, after ChatGPT but before agentic, I was asking AI for help with some projects. It kept recommending really good, well designed APIs, and gave me code snippets for them.
One small issue: they didn't exist! It had just hallucinated them!
Which was a real shame, since they were much nicer than the actual stuff I ended up finding.
I just realized, thinking about this now, that these days (and perhaps even back then), I could just say "ok now take this code and build the missing library so it actually works!"
Less external dependencies. I noticed Claude was vendoring (copy-pasting) Lucide icon svgs into my codebase (with proper attribution) because I was only using a small handful of them. That's awesome.
>Except when it's a license violation or in something that ends up having a security vulnerability.
What's more secure isn't so simple. If you vendor something with a vulnerability then it wont be patched. But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities. And it can cut the other way - you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks).
There is a balance that must be struck, and I think LLM's strike a better balance than people do. Dependencies are a convenience with a cost and LLM's can trivially copy or re-implement things that we cant.
> But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities
If you aren't using a library function you're not vulnerable to exploits in that code: unused but imported code is inert (possible usable as a gadget if you're vulnerable elsewhere, but at that point you're screwed anyways) and most compilers/runtimes completely eliminate it.
> you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks)
There are better mitigations to this than not using a library.
You still completely ignore the license violations.
Every time I try to get a npm based project running (or one of my forks of one), half the packages don't exist anymore or I need to spend hours fixing breaking changes.
It's usually more straightforward to just rebuild it from scratch — not to mention infinitely more satisfying — and that was true before AI!
Yes it does depend on the dependency, and a static asset is on one end of the extreme.
It depends on the "load bearing" code. Obviously something like crypto is not something we should implement ourselves but core business logic would be "load bearing" in another way and is probably not something you want to farm out to a dependency.
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.
Same except I had open source libraries, I just somehow always had a worse time with them than just building it myself. (Just even getting them set up in the first place, or updated, and so on... most of them seem to be someone's "always have stuff to do at my job" insurance policy!)
But even if they were pleasant and did what I needed (this one time I installed a 5000 line lib that was missing 20 lines to do the thing it was actually designed to do.. like, they couldn't have added 20 more lines?!), an issue I have is spoilers.
Like, at university, they constantly said, ok here's a big problem in computer science..
(3 seconds later) .. aaand here's how we solved it! And I'm like agh, no! Spoilers! I want to figure it out, jeez!
That's also how I feel about "computer, just magick my entire program into existence." Spoils the fun of figuring it out!
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.
It is... a meme? I think it is an explanatory construct that was invented by lispers who were facing the declining Lisp popularity back then in 90s. It was looking very promising, and then it just lost its steam and now almost no one uses it. One can imagine "Lisp is a bad language" as an alternative explanation, but most lispers do not (and didn't) agree and they prefer the Lisp curse, because it paints Lisp as a language that it too good for its success.
I'm not taking sides here, I love Lisp, though I don't use it anymore (except elisp in emacs, but it doesn't count). My point is that debating the name itself distracts from the actual issue.
I’m reminded of Chuck Moore’s practice of always reimplementing everything. There’s benefits and drawbacks to this; calling it a curse is certainly a strong opinion.
It really applies to all languages where the very process of developing extends the language. It is the modern day variant of the Babel curse: you end up with a perfect language for your problem understood by a single individual.
> 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.
If coding is anything like image generation, everybody is getting the same output anyway, which means we are back to nearly standard libraries just that are being dynamically produced. I see your claim as a new version of security through obscurity. It is way easier to patch all variants of a product when you can identify their lineage as variance in the first place.
What about the vulnerabilities you yourself introduce when using AI? or is the assumption that (1) there will be zero or (2) you won't ever open source so no one will know about them?
> 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.
Why stop there? Why don’t we build our own compiler and OS before starting a project? Because, well, "the cost of rolling our own has gotten so low". I’m not sure what to say; sometimes I think I live in a completely different dimension from some HN commenters.
> 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?
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.
"I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace."
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.
well i can't say for the whole community but i remember someone blogging around 2010 about dropping mainstream languages for his project because all the graph libraries he found were complicated to assess and inadequate.. so he went to write his own tiny lib on commonlisp and was done in a short time.
the lisp dialect growth is also famous, it's less the case these days because people know about it, but it existed
After programming in multiple Lisp dialects over 20+ years, it’s only sorta true. The biggest problem is that “Lisp” is ambiguous. Common Lisp? Scheme? Emacs Lisp? Clojure? They are all legitimate Lisps, but they all have slightly different syntax, semantics, and standard libraries. Even among some Lisps, there are differences (notably Scheme, though Racket has helped by becoming somewhat dominant in some areas). Common Lisp helped reduce differences at the cost of supporting almost everything it was seeking to unify, and yet still has platform gaps that implementations have to fill in. But within a given Lisp, there is a lot of reuse. Racket has a large set of libs. Clojure runs on the JVM and it’s common to mix and match Clojure and Java libs.
note that i'm mostly pro-lisp, and wasn't criticizing, just reporting what i saw when reading about it.
i'd add one thing to your point, is that lispers know how to port concepts from lang a to lang b very easily, support libs, macro layer if need be (see goroutines in clojure) so fragmentation is not as hard it was in mainstream languages
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.
I suspect it will continue as it has. Where LLM's do use external dependencies, but quite a bit less than people do. Saving it more for the things that are complex and sensitive. They aren't perfect but overall it's better than the non-agent status quo (more dependencies, less re-implementing).
Not sure about this; what would be an incentive for AI vendors to do this ? More libraries used means less tokens spent, so it runs directly against their business model.
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.
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 something
At 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 anyway
I 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.
How about (3): that in-house utility that you want to re-use across projects because it scratches one itch in precisely the way you want it scratched. Its raison d'être does not disappear from the appearance of LLM, it arguably gets stronger. You want the decisions that went into the library to be encoded in immutable form from the perspective of the contexts working on library dependents.
In the old days, both the investment in the library and the additional cost you'd want to sink on it to consider it publishing quality incentivised to keep it truly internal. LLM code however? It might be slop, but it's accurately groomed slop. Prompting the model to roleplay a public library author might even improve the output when it's in fact not published at all. The investment is low, the extra cost of sharing is low, worst that could happen is others actually picking it up and that would not be bad at all.
Is that spamming the public information universe on the faint hope that perhaps future models might come pre-trained with understanding of your library? Sure. But it's a very different thing from the scenarios described in (1).
>Not the end of free software - in fact that may end up flourishing with LLMs and reverse engineering and the like.
LLMs are antithetical to free software, which everyone seems to forget is as much an ethical and social movement as it is a classification of software licensing, and will be until one can examine and audit the training data of a model to exclude the possibility of including any non-free code, and until they include, document and respect the licenses for the sources they do use.
The degree to which they discourage people from actually being able to understand and modify code without an LLM also makes the code they generate implicitly nonfree. All of the freedoms of free software presuppose their utility to a human over their utility to a machine. If people aren't reading, writing and distributing code then it defeats the entire point. That's just proprietary software with extra steps.
I don't know what you call this new paradigm of vibe-coding and just not giving a damn about sources and licenses and copyright, but it isn't free software. And it's probably worth pointing out that said paradigm was created by and is most useful to corporations, not people. Using the plagiarism machine to plagiarize "the man" is still subject to the Rule of Goats[0].
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.
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.
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.
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.
In at least some cases, this is pretty clear cut. Don't roll your own crypto libraries. You may think you know what you're doing. You don't - not enough to produce genuinely secure crypto.
Don't roll your own numeric libraries. There are libraries with decades of improvements to handle corner cases and increase stability. You won't create a better one, not in one lifetime.
So, yes, in some cases code reuse through libraries really does improve software quality.
It fundamentally comes down to this question: Can I, the user of this library, produce a library that is more robust for my purpose than the existing libraries? Those who say "yes" often underestimate the amount of care needed to create code that actually works - that works solidly, that is robust against failures on certain inputs.
But, you say, you don't actually have any of those inputs, so why do you care? You don't - now. But the day may come when your program is going to have to handle those inputs, and when it does, then it's your problem, because you wrote the library.
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.
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.
I see that sbcl itself is alive and doing rather well, but other than that the landscape is fairly grim.
Unironically the most successful modern day lisp is clojure, that mostly piggybacks the jvm and can reuse most java libraries and frameworks.
I've used more Rust tools, and jobs are outside few niches non-existent.
https://gavinray97.github.io/blog/llm-build-cheaper-than-sea...
What if there was a code sharing site where it was unambiguous what a given snippet of code would be named and where it would be stored, so that a user could just browse it and find a list of implementations for a given problem?
This of course runs up against one what John Ousterhout notes is one of the most difficult problems in computer science --- naming things --- in his book:
https://www.goodreads.com/en/book/show/39996759-a-philosophy...
I've tried to do it on a small-scale with my own work, storing bits of (la).tex code in a single file, but on reviewing it, I'll often find that I have written a given solution a second time and given the macro a slightly different name....
As an example, a black hat doesn't get 70% of web sites from one shared bug in PHP. They need to target specific sites, and the exploit isn't likely to work in very many other places.
The one situation where they really can't get anywhere profitable is a unikernel webapp. With no source and no shell they find the vuln but the worst they can do with it is possibly poison or exfiltrate data as a one off, or crash the server. Often they can't even figure that out. Can't even leave themselves a reliable way back in.
Of course the traditional problem with unikernels is that you have to port EVERYTHING you need yourself. But the cheapness of this is exactly what we're talking about so.
Looks like security through obscurity's back on the menu.
Genetic monocultures like bananas are at risk from a single species of fungus.
One small issue: they didn't exist! It had just hallucinated them!
Which was a real shame, since they were much nicer than the actual stuff I ended up finding.
I just realized, thinking about this now, that these days (and perhaps even back then), I could just say "ok now take this code and build the missing library so it actually works!"
What's more secure isn't so simple. If you vendor something with a vulnerability then it wont be patched. But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities. And it can cut the other way - you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks).
There is a balance that must be struck, and I think LLM's strike a better balance than people do. Dependencies are a convenience with a cost and LLM's can trivially copy or re-implement things that we cant.
If you aren't using a library function you're not vulnerable to exploits in that code: unused but imported code is inert (possible usable as a gadget if you're vulnerable elsewhere, but at that point you're screwed anyways) and most compilers/runtimes completely eliminate it.
> you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks)
There are better mitigations to this than not using a library.
You still completely ignore the license violations.
It's usually more straightforward to just rebuild it from scratch — not to mention infinitely more satisfying — and that was true before AI!
On the other hand, I routinely build Java/JVM projects with dependencies that haven't been updated in a decade that compile without issues.
Somewhere in the middle are most languages, I think.
It depends on the "load bearing" code. Obviously something like crypto is not something we should implement ourselves but core business logic would be "load bearing" in another way and is probably not something you want to farm out to a dependency.
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.
But even if they were pleasant and did what I needed (this one time I installed a 5000 line lib that was missing 20 lines to do the thing it was actually designed to do.. like, they couldn't have added 20 more lines?!), an issue I have is spoilers.
Like, at university, they constantly said, ok here's a big problem in computer science.. (3 seconds later) .. aaand here's how we solved it! And I'm like agh, no! Spoilers! I want to figure it out, jeez!
That's also how I feel about "computer, just magick my entire program into existence." Spoils the fun of figuring it out!
I'm not taking sides here, I love Lisp, though I don't use it anymore (except elisp in emacs, but it doesn't count). My point is that debating the name itself distracts from the actual issue.
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.
Why stop there? Why don’t we build our own compiler and OS before starting a project? Because, well, "the cost of rolling our own has gotten so low". I’m not sure what to say; sometimes I think I live in a completely different dimension from some HN commenters.
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?
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.
"I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace."
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.
the lisp dialect growth is also famous, it's less the case these days because people know about it, but it existed
i'd add one thing to your point, is that lispers know how to port concepts from lang a to lang b very easily, support libs, macro layer if need be (see goroutines in clojure) so fragmentation is not as hard it was in mainstream languages
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.
(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 something
At 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 anyway
I 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.
In the old days, both the investment in the library and the additional cost you'd want to sink on it to consider it publishing quality incentivised to keep it truly internal. LLM code however? It might be slop, but it's accurately groomed slop. Prompting the model to roleplay a public library author might even improve the output when it's in fact not published at all. The investment is low, the extra cost of sharing is low, worst that could happen is others actually picking it up and that would not be bad at all.
Is that spamming the public information universe on the faint hope that perhaps future models might come pre-trained with understanding of your library? Sure. But it's a very different thing from the scenarios described in (1).
LLMs are antithetical to free software, which everyone seems to forget is as much an ethical and social movement as it is a classification of software licensing, and will be until one can examine and audit the training data of a model to exclude the possibility of including any non-free code, and until they include, document and respect the licenses for the sources they do use.
The degree to which they discourage people from actually being able to understand and modify code without an LLM also makes the code they generate implicitly nonfree. All of the freedoms of free software presuppose their utility to a human over their utility to a machine. If people aren't reading, writing and distributing code then it defeats the entire point. That's just proprietary software with extra steps.
I don't know what you call this new paradigm of vibe-coding and just not giving a damn about sources and licenses and copyright, but it isn't free software. And it's probably worth pointing out that said paradigm was created by and is most useful to corporations, not people. Using the plagiarism machine to plagiarize "the man" is still subject to the Rule of Goats[0].
[0]https://twitter.com/popehat/status/858722120620265473
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.
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.
Don't roll your own numeric libraries. There are libraries with decades of improvements to handle corner cases and increase stability. You won't create a better one, not in one lifetime.
So, yes, in some cases code reuse through libraries really does improve software quality.
It fundamentally comes down to this question: Can I, the user of this library, produce a library that is more robust for my purpose than the existing libraries? Those who say "yes" often underestimate the amount of care needed to create code that actually works - that works solidly, that is robust against failures on certain inputs.
But, you say, you don't actually have any of those inputs, so why do you care? You don't - now. But the day may come when your program is going to have to handle those inputs, and when it does, then it's your problem, because you wrote the library.
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.