The Lisp curse, now coming to your ecosystem
javahippie.net
javahippie.net
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've used more Rust tools, and jobs are outside few niches non-existent.
Not recently though, right now it seems the market has just been completely obliterated and it is hard to find any kind of job, regardless of the tech stack.
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.
So you design from the core logic and write shim to external dependencies. Instead of bringing deps from the get go.
Yeah but i don’t want to. Let’s say i need to connect to rds using iam authentication.
I don’t want to write code for that, i want to use a library.
I don’t want a library that works with chicken scheme but not on sbcl and maybe on cmucl.
I know i can, i don’t want to. I want to reuse code written and maintained by other people.
All the people that had that need wrote code for that. And I guess they don’t want to do unpaid work by providing a full fledged library.
> I know i can, i don’t want to. I want to reuse code written and maintained by other people.
Then I guess Lisp is not for you.
Aaand back to square one. Go tell to most of the industry and you get the lisp curse.
Thank you for proving me correct.
Given this elitist mindset of the lisp community, no wonder there’s a thing called “lisp curse”.
But then once I read the second paragraph, I agree with you. Lisp is doing fine in terms of important ecosystem libraries. The article sets that as the context when it asserts as fact that "established libraries are incredibly stable, tested by hundreds of thousands of developers, included in thousands of CI pipelines and maintained by experts on the topic."
It's akin to how Linux isn't a OS but a family of OS with same core.
And you haven't even seen the Clojure<->C++ interop in Jank. Anyone who has even the slightest clue of what's up says this is some kind of blackmagicfuckery.
I mostly don't use Lisp for work; we have some Clojure services, but they rarely require any attention - mostly when we need to bump dependencies. But I use a Lisp for personal stuff and I switch between different dialects multiple times a day - Elisp, Babashka, nbb, Fennel, Jolt, Jank - and the overhead is virtually none. I can't say the same thing about switching between JS/TS, even though I have used them for far longer than any Lisp.
And I am left wondering if it is that great why didn't it take over. I think you are ignoring some minor things that make it unpalatable for the most programmers.
Your comment to me sounds ironic because I don't even use Nix. I manage all my dotfiles in a single org-mode file and tangle them from there. It takes a few minutes to bootstrap a machine from scratch and makes my systems semi-immutable.
Comparison with nix on the surface sounds fair. Nix has steep learning curve, but most users once learn it, stay in it. Same can be said about Lispers - I have never met a person who wholeheartedly dove into e.g., Clojure and ever said it's [widely] impractical. There's unavoidable pain of getting into both, but the difference is where the pain sits. With Nix, much of it sits in the language and tooling: an untyped, lazy language with cryptic errors. With Lisp, the language is the simple part, and the cost is unfamiliarity and the ecosystem. Lisp's core is small enough to explain on a napkin, Nix's isn't.
> ignoring some minor things
I am not ignoring them, I speak from my heart. I know first hand how pretty much every mainstream popular stack lies to you about its own complexity. Neither Python nor Javascript are simple, small language ecosystems and I say that with full confidence after decades of using them. There's a real, practical wisdom of Rich Hickey's "simple vs easy" distinction and majority of programmers either don't know, don't understand, or don't care.
We really do have a good idea because we can see how much every language is used on github and we can see bulk job listings on the internet.
Just because the majority is required to be on Python, doesn't mean it's the best stack for solving problems.
So which is it? Secretly popular or it doesn't matter that it's unpopular because it's so great anyway?
Gathering language stats for Lisp is also challenging, because it's not a single PL - it's a whole family of dialects.
If you take them all together, they still don't amount to much.
Modern Lisp landscape is very, very different from LISP you're talking about (invented in the 50s).
The old lisp landscape actually had some people using it.
It might be time to accept that most experienced programmer have heard of and used lisp or a variant at some point and it just didn't offer a real pragmatic advantage. It was very influential when the alternative was putting in assembly instructions using their hex codes, but modern languages have adopted all the best parts. The parts that are still unique like s-expressions, macros and 'code as data' haven't really paid off as much as people like to pretend. If you have every program writing their own crazy DSL, things get very squirly very fast, because every program becomes it's own niche language.
Mixing 'code and data' is the same thing. The key to simplicity is to use simple straightforward data structures and keep the data and execution as separate as possible because data is static and easy.
It has been 70 years and many ideas were hugely influential while some others ended up doing more harm than good. People thought inheritance was a great idea for 20-30 years too and we're still trying to fix that damage.
Public GitHub repos and job ads measure open source and hiring. They miss private production code. Nubank runs a bank with 100M+ customers. Google Flights grew out of ITA's Common Lisp engine. Those don't show up much in either metric.
Just, spend a minute looking at Nubank's numbers. It is the biggest digital bank in the entire world. They grew from ~12M customers in 2019 to 131M in 2025 - almost 1000% growth in less than a decade. For JPMorgan (just for low-key comparison), getting to their ~80M customers took around 150 years and dozens of acquisitions. It's not totally fair, because I'm handwaving assets here and other things, but seriously, how can this story be just ignored?
> So which is it? Secretly popular or it doesn't matter that it's unpopular because it's so great anyway?
Both. "There's more than the stats show" and "popularity doesn't measure fitness" don't contradict each other.
> The key to simplicity is to use simple straightforward data structures
You're reciting word for word the Clojure philosophy. Rich Hickey's "Simple Made Easy" talk makes exactly your argument.
> they still don't amount to much.
Go check Github Language stats and see where Emacs Lisp sits there. And let me remind you, Elisp is not a general-purpose lang, it was made for one and single objective, it's an effing text-editor configuration tool. Once again, r/emacs gets daily announcements of new Emacs packages. I'm not even exaggerating, every single effing day there's someone posting about a new package. Are you seriously not curious to see who the heck all these people?
> It might be time to accept that most experienced programmer
I think you seriously need to study the demographics of Lisper communities. Maybe log into Clojurians Slack, or watch some talks from Clojure conferences. Majority of them are surpassingly experienced. Over 95% of them are bona fide programming language polyglots. Most of them either borrow ideas from other languages into Lisp or take what they learned from Lisp into other languages. They rarely bash on specific PLs, because the choice of a language for specific scenarios largely doesn't matter, they understand that. They are not language fanatics. Neither am I. I'm not telling you to switch to my "beloved language". Because Lisp is not a language. Lisp is an idea. And it is a very much a brilliant one.
> If you have every program writing their own crazy DSL
> Mixing 'code and data' is the same thing.
"Code as data" doesn't mean mixing data with execution. It means code is written as ordinary data structures, so tools, editors and the program itself can read and transform it trivially. Languages without it still build DSLs. They just put them in YAML pipelines, JSX, HCL, decorators and annotation processors, and each one needs its own parser and tooling.
> modern languages have adopted all the best parts.
They adopted GC, closures and FP idioms. Most didn't adopt connecting to a running process and redefining one function while it runs, or structural editing. Those still change how the work feels day to day.
> It has been 70 years
Yes! That's the point. Great ideas are timeless and the grand idea of Lisp as a practical notation for lambda-calculus is timeless. Even though it was not initially designed as a notation for lambda calculus, the way how it fits almost purely incidental. McCarthy invented a language and, by accident, found inside it a minimal self-describing core. That core is the timeless part, and it stays timeless because it was found, not designed. Whether anything in mathematics is truly "discovered" is a philosophical question, but Lisp is one of the stronger cases for saying so.
You're basically fighting with me if math still matters. Dude, of course it fucking does.
Not really, because if companies use it they will mention it when hiring. It isn't back up by any real information. You're basically saying that all data says the opposite, but it's used a ton because of the one example company. This is like when people say haskell is about to take over because someone at facebook used it for an email filter. Everyone gives the same exact example. Every popular language has about a million examples.
Then you are trying to argue that customers or growth of one company has to do with language adoption. Do you realize that this seems like a desperate backwards rationalization of what you wish was true?
watch some talks from Clojure conferences
I have, they are obsessed with the rabbit hole of language pagentry and never seem to end up solving real problems. It's all about more and more complex language mechanics and labels of complicated techniques.
Both. "There's more than the stats show" and "popularity doesn't measure fitness" don't contradict each other.
Saying it doesn't matter that it isn't popular contradicts it being popular.
Do you know where emacs lisp ranks? 49th, behind a half dozen languages I've never heard of and configuration languages.
Most didn't adopt connecting to a running process and redefining one function while it runs Those still change how the work feels day to day.
Agreed
Great ideas are timeless
Agreed, that's why lisp has been so influential. That doesn't mean it is objectively a good choice by today's standards.
the grand idea of Lisp as a practical notation for lambda-calculus is timeless
Maybe, but the truth is no one cares about that because it doesn't mean anything to productivity or better software.
You're basically fighting with me if math still matters. Dude, of course it fucking does.
This is a nonsense statement that doesn't relate to the conversation. You're giving something a label that no one is asking for then saying the label is super important. No one cares about this, people can already do what they want.
I never said Clojure or Lisp is "about to take over", besides you're trying to use one spam-filter system inside a PHP company example, against CircleCI, Metabase, Walmart, Grammarly, ITA/Google Flights, Cisco, Rate.com, Funding Circle, Netflix and bunch of other teams that use it in production.
> I have, they are obsessed with the rabbit hole of language pagentry
Just a random example from Netflix guys: https://www.youtube.com/watch?v=gJ9UZlr6C6M
There's tons of different real-life use case talks. From Boeing/Embraer, from Funding Circle, from CircleCI, from tons of smaller startups running things on prod. You're just insisting of something you haven't even bothered to give a critical look at.
> That doesn't mean it is objectively a good choice by today's standards.
Okay, tell me more about "today's standards". What do you mean? No language is "objectively a good choice". A choice is good or bad for a team, a problem and a set of constraints.
It is a great choice for specific use cases. Fintech startups notably finding that to be very true.
> it doesn't mean anything to productivity or better software.
Clojure's immutable data by default rules out a whole class of concurrency bugs, and I already gave you the real-world example: Nubank scaled to thousands of engineers on Clojure and Datomic. That is a large bet on the language at a large scale, but you're just choosing to ignore that. I get it, every niche language has its "company X uses it". But once again, I'm not advocating for a single PL specifically. I'm preaching the idea of a language. The idea you're just outright dismissing because "it would have converted everyone a long time ago."
I've been working in this field for decades. I have gone through over a dozen language stacks: different paradigms, tons of tooling, techniques, patterns, hype cycles and silver bullet calls. If I've learned anything, it's that the majority is not only not always right, but in most cases it is flat-out wrong.
You don't have to trust me on this (some rando on HN), just listen to renowned CS veterans with big names - Guy Steele Jr., Alan Kay, Sussman, John Carmack, Crockford, Yukihiro Matsumoto, Paul Graham, Uncle Bob, Steve Yegge, Dijkstra, Brendan Eich, Karpinski - there are tons of names who'd agree that Lisp is an everlasting idea.
Lisp endures. It is thriving; there are new Lisp dialects coming out every few years. Some of them are serious tools, not toys. You can realistically run Lisp on pretty much any platform today.
I'm not suggesting everyone should just drop whatever they use and switch. I'm just saying there are some ideas that are worth understanding and your view on where Lisps stands today is misguided.
> This is a nonsense statement that doesn't relate to the conversation.
I.e., "lambda-calculus doesn't help anyone ship software". Yeah, maybe you're right. Yet it is still in there, whether we want it or not - it explains why the software we ship behaves the way it does. So maybe it's worth understanding the language that explains it best.
Today, when mainstream languages have stolen much from Lisp, the benefit of using a language where you can generally just add a gem, egg, or crate is much higher than the benefit of the one thing that is still unique to Lisp: macros. Reflection is inelegant as hell when you compare, but it will get you almost all the way macros do.
At the same time, typed languages have become much more like dynamic languages. The types have disappeared into var and let statements; they are now inferred rather than repeated. Pattern matching has been added, and more—without compromising the benefits for larger teams and larger code bases.
Purists will disagree, but I haven't seen a real world problem solved in Lisp that I couldn't also solve in other languages.
And yes, I am interested in being proven wrong. I want to know what kind of problems still exist that are that hardcore. But I suspect a big part of it is that those who code in this still think the "hello world" for Java looks something like this:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
void main() {
println("Hello World");
}
Console.WriteLine("Hello, World!");
Lisp is an intellectual tower and has given an incredible amount to the programming community in terms of ideas and a playground for people to try things. I'm not denying any of that — it should be celebrated. But my thesis is this: most of that has been moved, copied, stolen, and adapted to mainstream programming languages.
Turing completeness makes "I couldn't also solve" an impossibly high bar.
But if what you mean is, you haven't seen macros used in ways that make you wish your day-job programming language had macros, that's fixable.
https://brl.sourceforge.net/brl_4.html#SEC31
Now, as a non-Lisper, I have to wait and hope the maintainers of programming languages I use will take useful syntax from other languages. Back when I was an active Lisper, I could take such syntax myself.
About back then, Perl/PHP/Python/Java/Ruby were never as good at pulling groups out of rows of SQL, but people could work around that by taking more time, writing more code, being more careful. So if you haven't seen macros used to make it better, you don't realize you're missing out on a huge deal. Maybe you just have a vague idea that things could be better, but you're too busy finding and fixing bugs to pursue this thought.
> if what you mean is, you haven't seen macros used in ways that make you wish your day-job programming language had macros, that's fixable.
is not true at all anymore? Or is it only true under very specific circumstances (if so, what are they)?
Also true if you want a shorthand syntax for defining a variable where the name of the variable is meaningful. JavaScript takes care of the most common case with destructuring assignment, but with macros you could make such syntax yourself.
Don't get me wrong I'm a macro fan. I've worked with some elegant codebases using metaprogramming but it's been challenging bringing people up to speed with super clear efficient - but novel - code,
Other projects that were just down the line Java boilerplate built on a well understood library worked just as well in other ways.
Personally I think reducing cognitive load is key, I've found people don't have the energy to work with clever code, even if it makes writing it a delight.
... and then llms happened, and I now don't write code at all but closely review a fire hose of mediocrity that gets the job done. I don't want that too magical.
Bruh... Nubank is literally the biggest effing digital bank in the world. Famously built on Clojure stack. Just because you have not seen shit it doesn't mean it's not happening.
Apple, Netflix, Amazon, Walmart, NASA - they all use Lisp, and that's just the States. There are tons of European startups building on it.
> Lisp missed its timing.
It is literally timeless. Emacs just turned 50. Name a single half-a-century old software product that's being actively used, developed and improved. r/emacs subreddit gets daily, daily! updates of new Emacs package announcements.
> most of that has been moved, copied, stolen, and adapted to mainstream programming languages.
Totally. Except homoiconicity. The point of which the majority of programmers miss, misunderstand, or ignore. The bigger point programmers miss is that Lisp effectively proves that largely the syntax of programming languages doesn't really matter. What matters is the runtime. And Lisp today runs practically on every possible runtime. Meaning that to be a polyglot, you don't really need to know dozens of PLs, you can just understand homoiconicity and voila - you can practically ship software for any runtime. Syntax is the cheap part, and Lisp shows it well: Clojure on the JVM and CLR, Clojurescript on JS, Fennel on Lua, Hy on Python, LFE on BEAM, Jank on LLVM, etc. The surface stays the same, and the host changes underneath. Then you learn runtimes and type systems, which is the real work of being a polyglot. That is a big win. Most programmers spend years on syntax and then mistake it for knowing a language. Learn the damn Lisp. It is enormously practical.
> still think the "hello world ...
Who the fuck cares about intricacies? In pretty much [almost] every Lisp dialect it would be just:
(print "Hello, World!")
For EVERY different runtime.
it's the developer experience
(and the combination of all features, including homoiconic macros)
> a real world problem
You can solve anything with enough sweat ;)
One example? Routific's core algorithm is written in CL (source: its author on HN). Why not Java, like everybody on his field at this time? Because it was too tedious (edit: and we're not talking only about syntax) (there's a blog post somewhere). His prototype evolved in efficient production code, now the heart of the company.
> my thesis: most of that…
agreed on "most". Many features appear here and there in other languages. But there's the parts and the whole.
And the living platform ("stop writing dead programs"), still unique (with Smalltalk).
In fact the main reason I hang around Java and .NET as my main tools, is that those development environments have taken many key features from those programming languages and development experience, to the point that where they still lose to them isn't that much relevant.
Additionally, now with AI code generation, the actual programming language matters even less, natural language can be translated to whatever programming language one feels like, at the whim of a Markdown paragraph describing the desired output, assuming it is supported on the model being used.
However it is kind of sad that we lost the last AI wave from Lisp/Prolog to Python, losing good machine code generation in the process.
And I have seen many real problems solved with Lisp, regardless, that is why commercial Lisps like LispWorks and Allegro are still in business.
Can you think of some domains where Common Lisp is a better choice than other languages? I have enjoyed Clojure for a lot of things, but I have not really found the features of SBCL useful for the kind of work I do.
For instance, restarts without unwinding the stack are cool, but for a server that's going to be running in production, it's not something I really leverage. I could use conditions to change the context of code called downstream, but I just haven't had a reason to do this yet.
This is an old blog entry about their Lisp history, https://www.siscog.pt/en-us
https://www.siscog.pt/en-us/blog/35-years-of-lisping-at-sisc...
Then you have ITA Software bought by Google, and the reason they have Lisp style guide,
https://google.github.io/styleguide/lispguide.html
Autocad has used Lisp as main scripting language for quite some time, although they also do .NET as well nowadays,
https://help.autodesk.com/view/OARX/2026/DEU/?guid=GUID-037B...
Note that everyone talks about SBCL, but forget that the ones that survive the Lisp machines like experience are LispWorks and Allegro Common Lisp,
Which if you want to have a taste how it looked like back in the day, some folks are trying to keep Interlisp-D memory from Xerox PARC alive.
(coalton-toplevel
;; Type classes are defined with the define-class keyword
(define-class (Eq :a)
(== (:a * :a -> Boolean)))
(define-type Color
Red
Green
Blue)
;; Type class instances are defined with the define-instance keyword
(define-instance (Eq Color)
(define (== a b)
(match (Tuple a b)
((Tuple (Red) (Red)) True)
((Tuple (Blue) (Blue)) True)
((Tuple (Green) (Green)) True)
(_ False))))
;; Type declarations can have constraints
(declare is-eql (Eq :a => (:a * :a -> String)))
(define (is-eql a b)
(if (== a b)
"They are equal"
"They are not equal"))
;; Multiple constraints must be wrapped in parentheses
(declare double-is-eql ((Eq :a) (Eq :b) => (:a * :a * :b * :b -> String)))
(define (double-is-eql a b c d)
(if (and (== a b) (== c d))
"Both pairs are equal"
"The pairs are not both equal")))The `(define-class (Eq :a) ...)` block is defining a type class called `Eq` with a type parameter named `:a`. Think of this as an interface that can be added after the fact. Most (all?) major OOP languages only allow you to declare interfaces when you declare a class, but in Haskell, and in Coalton that takes a lot of inspiration from Haskell, you can declare "interfaces" (typeclasses) on any pre-existing type, including ones coming from a library. Here, the `Eq :a` interface means that there must be a function called == (in Lisp even the operators are defined as functions) that takes two parameters of type :a and returns a Boolean.
`(define-type Color ...)` is defining a simple enum type. (You can do a lot more with it, of course, but this example is kept simple). Then `(define-instance (Eq Color) ...)` is saying "The type called Color is an instance of the typeclass (interface) called Eq". And since Eq requires a function called `==`, inside the define-instance block you have to define that function for the Color type. The pattern-matching should be simple enough that I don't think I need to explain it.
Now, the thing that makes this more powerful than interfaces is something I already touched on. Here the Color type is declared and then its typeclass instances are defined right away, which is the normal thing to do when you're creating a new type: keep all its code together. But if that Color type had come from another library that you imported, you would still be able to say "oh, and this Color type does implement Eq: here's the definition of == as applied to Color values". You're not restricted to only the interfaces that the library author thought to apply: you can take someone else's code and add interfaces to it! There have been several times when I really wished that were possible in C#.
Finally, the constraints before the => fat arrow are like declaring your function parameters as `public T isEqual<T>(T a, T b) where T : IEquatable`. This allows Coalton to catch, at compile time, any call to `is-eql` with parameters for which the `==` function is not defined.
There's plenty more at https://coalton-lang.github.io/manual/topics/whirlwind-tour/.
I mean it must employ gradual typing, right? So that it can interface with existing code that is untyped
But there are definite advantages to having Coalton know your types, which is why they give you a `(declare foo Integer)` form. This doesn't compile to any code, it's a compiler hint that tells Coalton that it can assume `foo` is an int, not a float64/double, which allows it to pick at compile time which implementation of + gets used in `(+ foo 5)`.
The 2025 video introducing Coalton at https://www.youtube.com/watch?v=of92m4XNgrM gives an example of what Coalton can do with knowing types. Robert Smith (the presenter, and the primary creator of Coalton) gives an example of a Fast Fourier Transform function that uses generic numeric types so you can call it on any number type: float32, float64, int-modulo-a-prime, whatever. He then benchmarks it, and it takes about 1 second to run 2 million times. Then he adds the single compiler hint `(monomorphize)` above the function declaration. This tells Coalton "Hey, instead of doing a dispatch table lookup in this function and calling different + implementations based on the type of the parameters, I want you to create two different copies of this function, one that will call the specialized float32 math functions, and the other one that will call the specialized float64 math functions." (Or three copies if you also called it with your int-modulo-prime number type). This eliminates a dispatch-table lookup and allows the compiler to produce much more specialized code. It comes at the expense of larger binaries, of course: he's explicit about how this is trading speed for size, so it's an opt-in choice you make (by adding a `(monomorphize)` declaration above the function definition) rather than something that Coalton defaults to.
But I've digressed. Yes, I believe (though note my caveat about not having used Coalton yet) that it would use dynamic types for code whose types it can't infer. But I'm pretty sure it would also give you a warning. If it gives you an error, the solution is to add a `(declare [name] [type])` line in the appropriate place.
Code that is outside of the purview of Coalton—raw Common Lisp code—is run in explicit (LISP ...) forms [0] which require the user to annotate the type and they add dynamic type checks to ensure the enclosed code meets the contract the programmer specified (unless UNSAFE is used [1]).
Also, the whole cult-like attitude from a number of people in the Lisp community was a big turn-off. All that “if you don’t get Lisp, you’re not smart enough, haven’t got enough experience, or just haven’t tried hard enough” BS gets pretty tiresome. Lisp is really simple. There isn’t much to “get”. Haskell/LEAN was much harder for me to “get” than Lisp. And LEAN absolutely blew my mind. Lisp didn’t.
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.
KMyMoney stopped importing (some) OFX files for me. I asked an LLM to debug.
It was a wild journey. An obscure bug in some QT library that was triggered because of something completely unrelated that I had installed briefly in 2019 (and uninstalled years ago).
I had it fix the issue by cleaning the leftovers from 2019, but it's still a QT bug. I had it do a writeup, but I'll never submit it. It's fairly sophisticated and I don't know QT code at all.
I believe I do have some sort of a reproducer, but I likely wouldn't understand even the reproducer script. I think it won't be taken well if someone files a bug, says "Here's a script that reproduces it", but himself doesn't understand what the script is doing.
For bug reports (at least IMO) a minimal example to reliably reproduce the error without any fuss is the basic building block. The reporter doesn't need to understand why it works let alone offer an explanation. In fact for complex projects more often than not any purported explanation will be subtly incorrect and actively misleading. If anything further "documentation" of bugs is unwelcome. Unambiguously demonstrate the defect and GTFO.
I'd still be wasting someone's time.
I'll probably put a write-up on my blog one day, though.
If an end user encounters an error while staying within the bounds of "expected usage" then the bug is guaranteed to be valid. You just don't necessarily know whose bug it actually is (for example a broken library versus broken usage of the library by the consuming program).
It's honestly not worth it. I understand both sides here, but people are going to have to come up with new ways of collaborating. Pull requests are likely not it anymore.
I've seen the same thing in Go, for what it's worth.
The code totally works, I'm not a denier there, but the interfaces are heinous if you don't keep an eye out. Mine wrote a Go function that passed a name variable as a string, but also embedded in 2 separate structs that were arguments. I've also seen it do re-validation of data multiple times in internal functions so everything has to return an error.
It's also stuff that sort of doesn't matter if an LLM is the only user. It probably costs some extra quantity of tokens, but not enough to be worth hand-grooming the code.
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.
https://gavinray97.github.io/blog/llm-build-cheaper-than-sea...
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.
The ones that you are imagining to happen? Its not a problem because you could simply observe proper licensing.
>If you aren't using a library function you're not vulnerable to exploits in that code
Not true, just because you arent calling a function doesnt mean it cant run. Read up on Log4Shell.
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.
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.
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.
Genetic monocultures like bananas are at risk from a single species of fungus.
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.
The language is restricted to permissions granted on startup and can only access the system via the runtime, which only supports a particular subset of linux syscalls. So, outside of the stdlib, whichever feature you need, you simply use an LLM to port an existing python/rust/JS/TS/Java library to the language and use it.
As the runtime has its own scheduler and GC, I have actually been wondering about the feasibility of skipping the linux kernel and making the runtime itself the "os." Given that so much modern hosting is actually done on virtual hardware, the drivers could be hosted within the runtime as well.
- statically typed from end to end
- closed and open/extensible types
- closed types are immutable, open ones have two variants: immutable and mutable
- arrays have two variants: immutable and mutable
- no OOP/classes. inheritance is nominal and mainly exists to provide access to class membership (is X a Y?)
- functions operating on data
- UFCS exists to provide nice features like "apple".substr(...)
- first class functions and closures
- monomorphized generics
- tailcalls
- operator overloading
- modules and namespaces to control access
- erlang/beam style first class processes. So you `spawn` a function and communicate between processes using send/recv instead of async/await
Processes are completely isolated at the runtime level. Each has its own stack, heap, mailbox and GC.
The bytecode carries all type information. The VM will compile using AOT-on-load.
My own runtime-becomes-a-os idea is still just an idea. I haven't really pursued it with seriousness. Will probably do that once the language and runtime stabilize.
I started in March and have gone through nearly 300 spec revisions for the runtime and language. Thanks to LLMs, I think I will have something useful to share in 2027.
My problem is that I have ten things in the pipeline at any given moment and I switch between them as time permits. So things get delayed a bit.
A bare bones microkernel?
The advantage there shouldn't be obscurity, so much as very limited attack surface in the whole exposed stack.
But putting ssh for those bounce boxes on a nonstandard port that doesn't even show up to a remote system within the network until they've port-knocked on another two or four ports in the proper order on top of all that does not hurt security. Using a separate internal DNS zone that nobody outside your network has access to resolve doesn't hurt. Having your firewall drop packets from invalid sources instead of rejecting them doesn't hurt.
Which, probably, you will also have to do.
I suspect that a more effective mitigation to having exploitable bugs would be to have an LLM read all your HTTP requests and the actions the web server proposes to take in response and give a Jev-like approve/disapprove decision.
My point is that everyone doing their own thing their own way means an attacker doesn't get the next thousand sites for free after finding a vulnerability in one site.
Having an LLM as sentry is a fun idea too.
Big picture, I think we should explore what's possible when software is disposable.
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!"
That was, in retrospect, an important bellwether.
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....
Almost everything else is domain specific where you have to understand the domain first before understanding the code. And modeling a domain is all about tradeoffs between accuracy, performance, specific vs generic,…
Instead of collecting such solutions, a better approach is to master basic data structures, and then improve your modeling capabilities. After that, it’s mostly learning domain as they come (dsp, physic modeling, operating system concepts, relational database, graph theory, 3D geometry, accounting,…)
(LLMs accelerate this and "a few years" can easily turn into "a few months".)
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.
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? We could eliminate all external dependencies and even build our own compiler and OS, since the cost of rolling own solution has apparently gotten so low, right? Sometimes I feel like I'm living in a completely different dimension from some of the commenters here.
It’s about the relative chance that someone’s CI infrastructure somewhere in the dependency change gets pwned in a way that allows malware to get into our dev environments or production servers. If we roll our own library for some functionality we need, that risk is 0. My point is the cost of doing so is much lower than it used to be, both in terms of implementation time and maintenance effort.
Also, you clearly don't work with products that have any sort of serious corporate liability. Being able to blame a supplier/library is almost always preferable to assuming the liability yourself
I work for a company that provides compliance services to banks, we take our security responsibilities very seriously.
The risk associated with introducing a new dependency to the codebase has now exceeded the risk associated with implementing something ourselves in most cases (the exceptions being the obvious ones: crypto, auth, server frameworks, etc.).
> Being able to blame a supplier/library is almost always preferable to assuming the liability yourself
We like to optimize for actually keeping our customer’s data safe, rather than covering our butts :)
> We like to optimize for actually keeping our customer’s data safe, rather than covering our butts :)
If you have the budget to back that up I'm jealous. Otherwise, pride cometh before a fall. I'm curious how you conducted that risk analysis. Just because a common COTS library has more documented vulnerabilities doesn't inherently mean your hand-rolled option has less, and the difference would naturally vary from library to library.
For my part I work in defense, and our customers prefer to hear that we're using industry standard libraries and have tons of questions if we're rolling our own stuff (first of which is "why are you wasting our time and money reinventing the wheel?"). It reduces liability for them as well, they can tell their higher-ups that they approved proven, industry-standard solutions as much as possible and they're only paying us for our unique expertise.
Most of these huge AI discoveries of vulnerabilities have not been through probing an unknown server with a custom stack. They've been through probing a known/discoverable tech stack that is open source. Security through obscurity is never good, but if anything, the next couple years on known tech stacks is going to be worse.
> Being able to blame a supplier/library is almost always preferable to assuming the liability yourself
This only works if it's Log4j, or PHP, or some big vulnerability that hits mainstream news. Clients do not care if the tiny library only you picked had a vulnerability in it, and they shouldn't either.
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.
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 (ps: even though today everybody goes into ast / transpiler to experiment)
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.
Looking back, AmigaOS was remarkably complete and modern for 1985: preemptive multitasking microkernel, shared libraries, multimedia support, everything was modular.
That last fragment. I fear increasingly less so. There's already been a number of posts pointing out that modern programming is often held up be a few key individuals. And now (some of) those individuals (Linus, people like Chris McCord of LiveView, etc), are sharing how they're now "doing more of the stuff they've always wanted to do", and offloading tedious stuff to AI tools (by the way, expertise comes through tedious reps).
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!
It seems sort of wasteful of tokens!
REPLs in non-homoiconic languages like Python, and homoiconic Lisp do differ. Every single step in Read-Eval-Print-Loop does. That's why Lispers sometimes refer to Lisp REPL as a "true REPL", because in practical comparison, Python's REPL is more like an "interactive shell". Homoiconic means that code-is-data, and the Read step in REPL doesn't need to do any acrobatics with parsing, building AST, etc, it's just directly reading the code and passing to Eval as is.
Here's a sense of what it looks like to be writing software with Lisp: https://youtu.be/tHgApFhevrQ?t=2272 I purposely moved the marker so you don't have to watch the whole talk. Jeaye here coded his entire presentation from inside a terminal, embedded into a game.
That's how typically Lispers write software - "from inside out". Lisp, uniquely fits for LLMs, because when you give them a Lisp REPL, they stop guessing and start empirically analyzing current state of things and produce working solution faster, costing fewer tokens.
The typical flow with non-homoiconic PLs is is roughly the Unix/pipe model - batch-style. Agent spawns process -> reads stdout/stderr -> spawns next process. State lives in-between the calls and in files. Each tool invocation technically stateless. It is a whole different story with Lisp.
> It seems sort of wasteful of tokens!
Clojure is proven to be one of the most token efficient languages. https://tokencalculator.ai/most-token-efficient-languages-fo...
> It seems sort of wasteful of tokens!
This was referring to the LLMs' tendency to blat out hundreds of tokens into a single tool call, not to Clojure.
The REPL in the part of the presentation you link to only evaluates two forms, (range 10) and (bounce!), neither of which takes much advantage of homoiconicity.
cchase88 was talking about a degree of homoiconicity in Tcl that has been abandoned by most dialects of Lisp:
: ~; tclsh
% proc deproc {name} {return [list proc $name [info args $name] [info body $name]]}
% deproc deproc
proc deproc name {return [list proc $name [info args $name] [info body $name]]}
% proc ack {m n} {
if {$m == 0} {
expr {$n + 1}
} elseif {$n == 0} {
ack [expr {$m - 1}] 1
} else {
ack [expr {$m - 1}] [ack $m [expr {$n - 1}]]
}
}
% deproc ack
proc ack {m n} {
if {$m == 0} {
expr {$n + 1}
} elseif {$n == 0} {
ack [expr {$m - 1}] 1
} else {
ack [expr {$m - 1}] [ack $m [expr {$n - 1}]]
}
}
However, the reason I thought this model behavior was relevant is that, if the LLMs are squandering tokens by failing to take advantage of the REPL facilities available in Python and Node, they might also squander tokens in the same way when attempting to use languages with better REPL facilities, such as (let's stipulate) Clojure. It sounds like you've observed that my prediction is incorrect in real life. Can you go into more detail? Which harness and which models have you seen good results with, and can you show an excerpt of a transcript?
Without evidence, I suspect that the behavior may be due to LLMs being trained to do well on noninteractive (one-shot) SWE benchmark tasks.
Of course, there's no tool without flaws. Nevertheless, oh boy, how amazingly practical Lisp-dialects can be in reality (even with all their imperfections), it's just astounding. Sometimes I think maybe it is some kind of ego-defeating stance or whatever, maybe smart programmers just can't believe how the stupidly simple idea of Lisp can ever satisfy their galaxy-sized brains? To me, Lisp is like a boundless sea of incredible idea generation on the spot, turning it into practical reality like some magic. Effortlessly, painlessly, and with joy.
I don't know, maybe I had to go through the pain of learning the intricacies of a dozen different stacks, using them for years, only to discover Lisp later in my life. Perhaps I wouldn't know the difference otherwise?
Just the other day, I was watching a YT video, which I of course fully control directly from Emacs - that is very useful for taking notes. I can mute, pause, speed-up, rewind, toggle subs, etc. All while typing a message, a note, or while looking at a PR diff. I thought, "hmm, floating window would be nice". Without even missing a beat, I opened eca-emacs buffer, I didn't even have to type the prompt - I used speech-recognition. Agent then (running in Elisp REPL), connected to my WMs REPL driven by Fennel, using tools in my Clojure-made harness with its own REPL, tapped into the lua-based mpv, analyzed things on the fly and just built the solution, right there. I didn't even have to compile, restart, reload, refresh anything. Now I can detach a video playing in the browser into mpv window and later put it back. With a press of a key.
It's almost as if Lisp has been quietly waiting for this moment. LLMs and Lisp REPLs make such a great duo - if you're a programmer and haven't seen it in practice yet, you should seriously be experiencing deep FOMO right now.
> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
there is an infinite proliferation of Lisp implementations, and for many people it is the first language that they write an interpreter for since it is so easy.
Ecosystem split is the same reason why Cobol fell out of being mainstream: there are multiple proprietary implementations that are intentionally mutually incompatible, therefore an ecosystem could never develop. Oracle (in the past Sun) tries to avoid Java sharing this fate by using trademark law to crack down on JVM implementations that call themselves Java without having run the TCK.
Emacs Lisp I can't speak to, having no experience there.
As for Scheme, you're correct that implementation fragmentation is one of its problems holding back adoption. But it's not a problem for Common Lisp, which has had much less fragmentation issues.
> If we ignore the fact that established libraries are incredibly stable, tested by hundreds of thousands of developers, included in thousands of CI pipelines and maintained by experts on the topic
is not true for essentially any of the infrastructure that cutting edge biological research builds upon. It's all a buggy mess.
Expect dramatic acceleration in basic research as a result of LLMs.
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.
Natural selection says programs and libraries will stabilize and continue to evolve.
(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.
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://www.urbandictionary.com/define.php?term=Popehat%27s+...
It would be one thing if this were only the case for professional development, or if AI were really being used as "just a tool" but it seems to be the dominant paradigm with AI everywhere, that LLMs have to "win" and all human involvement in coding has to be eliminated. A world where the dominant culture around LLMs was to actually use them for education and aiding code generation instead of entirely abrogating oneself to a black box dopamine machine would be infinitely better than the world we have.
At the core of Free Software there is one simple kernel: the user being in control. Licensing and copyright is used to achieve that, but they're the means, not the goal. The goal is that you, the user, should be in control of your computing, not the developers of the software you are using. Hence software that is free i.e. the software not being bound by the whims of its developers.
From that perspective, IMO, LLMs are far from antithetical to Free Software exactly because they let[0] their users do whatever they want with the software and their computers. That a user can instruct their agent to take the video playback code from MPV and combine it with the UI of XBMC[1] while ensuring it runs on the Raspberry Pi 4 they have connected to their TV (that they "jailbroke" to remove the intrusive ads and other user-hostile software that they replaced with software to their liking) even if they barely have any programming knowledge themselves is a sign of software freedom.
[0] at least the user-aligned ones not bound by restrictions placed on them by their own developers, so perhaps we need a Free Models movement too or something along these lines.
[1] random example, i don't even know of XBMC uses MPV's code already, so assume it doesn't
And because LLMs can't be audited and can't track or respect the licenses of the software they use as sources, no software generated by an LLM respects the freedoms of Free Software.
>That a user can instruct their agent (...) even if they barely have any programming knowledge themselves is a sign of software freedom.
It isn't, because as I said, freedom presupposes knowledge. If you barely have programming knowledge and you don't understand the code an LLM generates then you can't 1) read it, 2) edit it or 3) redistribute it without an LLM. You are not exercising any freedoms in that case, you're just being a consumer of a service.
>so perhaps we need a Free Models movement too or something along these lines
I said what I think would be the minimum requirements for a model to respect free software - at the very least it should only be trained on free software, it should be provably auditable without hallucination (I don't even think this is technically feasible) and it should respect the licenses of the software it incorporates, including attribution where necessary.
Beyond that there's still the problem that training even open weight models requires expensive infrastructure making it implicitly proprietary. As long as we need data centers at all it's never going to be as free as a text editor.
LLMs, even by the limits they have from their training, can be used to give more control to their users than what they have.
Yes, being able to train an open source (not just open weight) model that is fully aligned with the user would be the best scenario, but even without that, LLMs can still give users more control over their computing than they previously had - even within the confines of current copyright laws, if they so desire.
Because free software as a movement depends on the existence of licenses and copyright. Without the ability to legally enforce and defend those licenses it would be completely meaningless Just as any freedom is meaningless without a means to enforce and defend it. And as LLMs don't even allow the means, they can't be useful in reaching the goal.
The goal is for people to have control over their software - direct control, not control as determined by a mediator or service.
>LLMs, even by the limits they have from their training, can be used to give more control to their users than what they have.
We disagree on what "control" is in this context.
I don't believe prompting a service to generate code you can't understand and thus can't use without that service is control over code in any meaningful sense, any more than ordering food at MacDonalds is control over the menu.
>LLMs can still give users more control over their computing than they previously had - even within the confines of current copyright laws, if they so desire.
They can't, because LLMs don't respect those laws. It doesn't matter what license you use, it just gets sucked into the plagiarism machine like anything else.
Also, people had more control before LLMs because they didn't need to use LLMs. Knowledge is control. An empty text editor is infinitely more freeing than burning token on Claude (or whatever) will ever be.
Ihe whole "Imaginary Property" (cute) charade is not rapidly headed to obsolescence. LLMs will only centralize control of IP to the corporations that will run their own LLM services, or license them to the services that will generate all of "your code" in the future. And under their terms of service, anything you generate will belong to those services, and not to you.
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).
Instead of "here's some small bits of code you might find useful" or "let me share my approach", the personal glory building style of OSS construction can and has tended towards "behold my framework" and a brand, and often even a VC etc funded entity to go with it.
I don't love LLMs just conjuring half-assed things into existence, but I've also been burned too many times by someone else's frameworkization of something that should just be a small modular bit, or part of a standard library. Languages like Rust that have exempted a lot from their standard library that frankly should be there suffer from this the most.
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."
Even if you need a small part of the functionality you bring in whole library when you use it increasing your exposure.
Standard way of doing things might impede better way of doing things for each particular application. And so on...
LLMs alter nearly every parameter in every value calculation.
Future software will often have single digit dependancies and userbase of 1.
The curse actually exists in every codebase; LISP just makes it more obvious.
I previously administered a service in Python that included
- a postgres backend
- alembic to handle migrations and sqlalchemy to do ORM bindings
- strawberry to supply a GraphQL API
- an autogen library to create a Python wrapper for that API, and then additional hand-written glue atop that because the autogen had flaws.
There is some chance that if you get air-dropped into our codebase, you might be familiar with all those pieces. But if not, you still have a learning curve to get what's going on.
The only advantage Java, Python, etc. ecosystems have is popularity, which makes it more likely that someone's bespoke solution has become standard enough that you might have heard of it before. There are still probably 2 or 3 dominant frameworks that you might or might not have seen entering a new codebase (and then a bunch of special-casing and glue code to match the almost-there abstractions to the actual problem domain).
A different way to frame this would be to say: why don't we all just pick one programming language and platform and use that? It's silly to reinvent the wheel!
The answer, of course, is obvious.
Diversity of solutions is good. Heterogenous diversity of solutions is even better. Good old Mother Nature is totally unafraid of solving the same problem, multiple ways, multiple times, through completely different means. That is true system redundancy.
It was true that anybody could create anything before the advent of LLMs as well. The barrier to entry was just higher than it is now. The bar for creating some quality is still pretty much as high as it ever was.
Tech is an eternal cycle always repeating itself. For example, did you know that it was a battle to create Fortran? John Backus had to go out and convince the high priests that there was value in using a language. Just like with LLMs, it was seen as as not being able to produce expert-level-quality-output and not something for serious people. Time flows like a river, and history repeats itself.
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?
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.
lol but still true
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.
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.