[ssivark]

The core thesis of this essay is reminiscent of the Lisp Curse [1] / Bipolar Lisp Programmer [2].

It's been a few years since I read these, but if I recall the argument there, it was that Lisp makes it so easy to build stuff and scratch exactly your own itch, that there's no real strong push for lisp programmers to come together and collaborate to build non-trivial and general purpose artifacts. And that is why the landscape of public lisp software is poorer as a result, compared to languages which demand much more effort to get anything substantial done.

Armin seems to be making a very similar point about AI coding.

[1] https://www.winestockwebdesign.com/Essays/Lisp_Curse.html

[2] https://www.marktarver.com/bipolar.html

[mattmatheus]

Assembly programmers made the same argument. It seems that we revisit this same trope each time the practice of software engineering undergoes a paradigm shift.

Some have a harder time with the transition than others.

[ozozozd]

Are you implying the author of one of the best, if not the best performing agentic coding harness is having a hard time with vibecoding as a new paradigm?

I’d look him up.

[ryan_n]

Someone could make the best agentic coding harness in the world and still have a hard time with the drastic changes that are happening in their profession. The two aren't mutually exclusive.

[zephen]

> compared to languages which demand much more effort to get anything substantial done.

It is not clear at all to me that other languages "demand much more effort" for the same end result.

It is clear that many non-lisp programmers value syntax, and many lisp programmers don't. Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp. I'm still awaiting psychological studies on this, but the rift is so large, I think there may be some significantly different brain processing going on between the two groups.

To your point, yes, it is also clear that, to the extent that lisp can match the productivity of other languages, whether it exceeds them or not, one of the tools that is needed to achieve this productivity boost in lisp is heavy usage of homoiconicity, and this results in every serious lisp program being a collection of DSLs, each of which is only understood by one person or very few people.

[kazinator]

> Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp.

I can guarantee you that most of these simply didn't go far enough; they had their "minds blown" with too little. They latched onto a highlight or two, found a way of sort doing that in C++ or Javascript and moved on.

There are people who have had their "minds blown" by time/mass dilation of special relativity, or phenomena in quantum physics, who don't actually know anything about physics; they couldn't work out how far a canon ball will land fired at a 45 degree angle with a certain velocity, though they can crack jokes about Schrödinger's cat.

For those of us sticking with the Lisp program, in one way or another, it was more of a sequence of small revelations in a progression of topics. Oh, that's a good way of representing that; that is pretty nicely thought out; that fits well with that; they had that how many decades ago? Sheesh; ...

Then once you start grappling with the Lisp issues, and kick the rock farther down the road, even in some small way, you are invested.

[zephen]

> I can guarantee you that most of these simply didn't go far enough;

And I can guarantee that I knew, when I wrote my comment, that I was summoning this very "No true Scotsman" argument.

> they couldn't work out how far a canon ball will land fired at a 45 degree angle with a certain velocity, though they can crack jokes about Schrödinger's cat.

It always superciliously starts with how true lisp people are the most brilliant ever.

> Then once you start grappling with the Lisp issues, and kick the rock farther down the road, even in some small way, you are invested.

And is eventually undermined by an admission of cognitive inflexibility, although not usually so quickly or in the same comment. Good job!

[kazinator]

Ha! For a second it looked like there was a debate here.

[zephen]

What's the point? There's nobody here but you and me.

[Timwi]

That's right, you're all alone in this private chat room.

[nico]

> Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp

For me, the answer to this is economics. Even if you love lisp, there are way more companies hiring for stacks that don’t include lisp

If you then optimize for employability, which I assume most developers do (not all, but a large percentage), you might end up with not that many people practicing lisp regularly

[zephen]

> For me, the answer to this is economics. Even if you love lisp, there are way more companies hiring for stacks that don’t include lisp

Certainly. But why would that be? It couldn't possibly be that the programmers already there built a system using the tools of their choice, and that system is now running well and deemed maintainable enough they require additional developers for the same language, could it?

Sometimes, of course, companies change their implementation language. The most famous cases I know of this are Viaweb and reddit, where the companies moved away from lisp. The company's main motive in this, of course, is making money. If they have a good product that is deemed maintainable, why would they piss off the original team, who probably chose the language, by switching languages?

Many programmers have worked in lisp. Studies have shown that programmers routinely learn new languages and somewhat forget old ones; older programmers are typically only currently proficient in as many languages as younger ones.

A company with a successful product is going to attempt to leverage that success. Whether leveraging it looks like incrementally improving it, or like treating it as a prototype and throw it out, will typically be a long conversation between developers and management. Typically incremental improvements are greatly preferred; it is only when all stakeholders become convinced that a fresh start is required that massive changes like implementation language will take place.

The calculus, of course is changing with LLMs. See, for example, the recent migration of bun away from zig. That rewrite was spearheaded by a massively effective lone developer, the exact persona that is claimed to always prefer lisp. Sadly, he chose rust.

[est]

I felt the same on Feb. Wrote a blog about it

https://blog.est.im/2026/stderr-06

https://news.ycombinator.com/item?id=46669591

[segmondy]

Is it really the same argument? I think there's enough of people that will argue that there will be no need to come together to collaborate, just rally a bunch of agents and you can build whatever non-trivial stuff you can imagine.

[baq]

Au contraire if typescript and rust didn’t steal the whole show it’d be a great time to be a lisp LLM pilot: agents can explain pretty much everything without any confabulations nowadays, so the understanding problem essentially goes away, if you care, which is exactly the point of the article if you ask me.

[ares623]

But at that point why use Lisp (which LLMs have been so far still to struggle to get matching parens every now and then)

What made Lisp cool and powerful goes away when you do it through an LLM.

[sroerick]

I have a web framework running with a lisp interpreter built in, and I think it unlocks a LOT for the LLMs.

[baq]

lisp can do things that make the currently accepted as standard best practice software engineering processes redundant, but it needs a different set of processes which I’m not sure are written about anywhere since apparently nobody is running with e.g. hot patching of application code

[sroerick]

I'm doing fully interpreted Lisp with the AST stored in Postgres. I can access the REPL remotely and I honestly dont know if I'm ever going to build an API or CLI again

[Aeolos]

This sounds super interesting. Do you have any blog or pointers where I could read more about this?

[sroerick]

https://pricklypear.rocks/welcome https://pricklypear.rocks/code

Just to be clear this is not a release, lol, I just made it to show a couple buddies. My one friend was saying he learned a lot just by reading code and pointing Claude at it and asking questions about what he didn't understand. It is provided as-is with no warranty, or installation instructions. If you really get stoked about it I could probably clean up multi user stuff a bit to get you logged on, but I think even just the idea is pretty neat.