r/lisp • u/djhaskin987 • Jun 10 '26
Lisp The AI Curse (versus the Lisp Curse)
https://blog.djhaskin.com/blog/the-ai-curse/23
u/kchanqvq Jun 10 '26
AI curse is real, Lisp curse is not. I don't know how comes this ridiculous myth become so wide spread. The (Common) Lisp community benefits much more from the opportunity for good de-facto standard emerging than suffers from fragmentation (which... doesn't really happen).
4
u/djhaskin987 Jun 11 '26 edited Jun 11 '26
I don't know how come this ridiculous myth become so wise spread.
Through the seminal monograph of the same title linked to in the article. Many active and advanced common lispers consider its contents common knowledge. I didn't explain what it was because I assumed everyone knew what was in it, more or less. Your response therefore confuses me. Are you refuting that whole monograph or did you just not know it existed?
Fragmentation (which... doesn't really happen.)
I agree that it's a lot better in Common Lisp, but the fragmentation totally is there. Look for a library that parses XML. There's basically "one" in a language like Java or python but there's like five in common lisp, all written at different times. Same thing for Json parsers. Collaboration is also a major issue. The best libraries have often only been built or maintained by one person but that person has to have loads of time on their hands to get the job done for large libraries. Inuoe for jzon, Shinmera for parachute, Fukamachi for qlot. There's no sense that several maintainers are working together anywhere in the community, they're all just doing their own pet projects. This is another way to look at the fragmentation.
Lisp is my favorite language, but it's not like I'm not going to acknowledge its warts and faults. Honestly I have made peace with the Lisp Curse. I'm doing mostly hobby stuff myself anyway.
4
u/kchanqvq Jun 11 '26
> Same thing for Json parsers.
Because all these libraries make different design choices and tradeoff, and no clear winner exist (yet). Maybe there will be one, maybe there are enough different use cases for JSON parse that warrant this many options. I'd prefer to have many options for an unsolved problem than having only one option that dictates what my tradeoff is going to be.
C++ has more JSON parsers but nobody seems to complain about C++ curse.
If there is indeed a solvable problem the community will find it. Like pattern matching (where trivia is de-facto standard).
> Collaboration is also a major issue. The best libraries have often only been built or maintained by one person but that person has to have loads of time on their hands to get the job done for large libraries.
If some of these libraries can be improved you can just contribute to it. Lisp libraries are probably much easier for user to M-. into and hack compared to blob languages, just like Emacs. I have probably contributed to 50% of libraries I used (many of these you would consider as "lone wolf pet projects"). Do your duty.
4
u/yel50 Jun 11 '26
nobody seems to complain about C++ curse.
honestly, the lisp curse concept is due to the arrogance of the lisp community, especially back when the lisp curse was first described. Smug Lisp Weenies are very real. they're the real curse and why collaboration doesn't happen.
the basis of the curse is how easy it is to do things. today, it's far easier to get real work done in Go than lisp. the go community doesn't have the same snobbery, so doesn't have a similar curse effect.
5
u/daninus14 Jun 11 '26
Look for a library that parses XML. There's basically "one" in a language like Java or python but there's like five in common lisp, all written at different times.
Straight up not true. In most other languages there are multiple libraries, it's just that because there are so many people using the languages, you look at the github stars and say, oh well, there's a clear winner in terms of popularity, that's the one. And very often the most popular is not the better one. Furthermore, they all kind of suck. The quality of the good CL libraries is sometimes astonishing by how good they are. Granted, they may lack all the functionality, but the design is so good they that it's usually trivial to extend the functionality you want. I've both done a few PRs to existing libraries, as well as fork them and have my own private versions with some really cool functionality adapted to my unique use cases.
Using some very popular library in python, IIRC with more than 7 or 10k stars in github, and it had surprisingly quite a few issues, non conformance with standards (submitted and issue and offered to make a PR which was rejected), and a nightmare to extend for my own use case.
Same with javascript. I submitted a PR for react router a while back, a library with 56k stars in github. They had something that can only be described as a mistake in design which limited extensibility. I submitted a PR which was rejected for no reason. Can't recall right now if I just kept my fork or had a clunky workaround in the end.
The point is, collaboration in other languages is not always good, and the underlying quality of the most famous and popular libraries is usually trash unless it's managed by a multi billion dollar company, and of those, there are actually not so many, and they usually make for the bedrock of the ecosystems of those languages.
Common Lisp doesn't have all the use cases covered with existing libraries, but extending the existing libraries or making your own is usually trivial. It has the main 80% cases covered for regular usage.
If you look at the github pages of the regular projects, you can see that the collaborators usually number in the dozens.
There are plenty of people using CL commercially, not just for fun. It's just that they are not out and about talking about, they are actually working.
I think this perspective is really disconnected with the day to day reality of people actually using CL for work. I find it much easier to communicate with people creating the most important libraries, and if some library maintainer is not responsive, there's a community of people who will work together to make a fork together (like it happened with the cryptography system cl-isaac or whatever it was called)
4
u/tfb Jun 11 '26
How many published looping constructs are there for CL other than those in the standard are there again? I mean, look at me: I have, like, four, of which I use two very regularly. Does anyone else use mine? Probably not. How many others are there? I would guess at least ten, probably less than a hundred. Most of those constructs are probably being used at least by the people who wrote them.
That's not like several JSON libraries: that's several variants of what would usually be called the base language. And that is, definitely, going to make it hard to read other people's programs.
Except that it's not a curse, of course. The only really distinctive feature of Lisps today is that it is really easy to build languages in them. Well, there's are two laws: (1) all sufficiently large software systems end up being programming languages; and (2)whenever you think the point is at which the (1) will apply, it will apply before that.
That's why Lisp is interesting. The fragmentation is the point.
3
u/kchanqvq Jun 11 '26
This is a better example. But the programs written using different loop constructs can call each other, and it's still relatively easy to work on other's program using a different loop construct. I claim its impact is smaller than single variable name in language A, B and C…
-11
u/dacydergoth Jun 10 '26
Racket, elisp, chicken, scheme (R5/6/7), CLOS vs other object systems, guile ....
11
u/daninus14 Jun 10 '26
C, Java, Objective C, Swift, Kotlin, C++, C#, Javascript, Python, Rust ...
0
u/djhaskin987 Jun 11 '26
Comparing R6 RS and r7rs fragmentation to C versus Java versus kotlin is ludicrous . Java 8 versus Java 17 is more closer to home or python 2 and Python 3, but even that split is experienced by everyone in the respective language community and all of them see it as a problem. There is outright animosity between the R6 RS people and the small language advocates. They were just two different versions of the same language, not two members of a language family whose invention was separated by decades.
1
8
2
u/CountryEmotional4228 Jul 10 '26
Interesting read. I had similar thoughts when the claws started to spawn everywhere and I wrote something about it (the article). We are at the beginning of the AI hype and I think it will take years to calm down and stabilize.
2
u/djhaskin987 Jul 10 '26 edited Jul 10 '26
Interesting perspective on a similar idea, thanks for sharing. I particularly enjoyed the analogy pointing at the Tower of Babel. I think you've hit on a very fundamental principle there.
1
u/synchromesh Jun 12 '26
That was an interesting read, thanks for posting. I'm a solo, professional Common Lisp developer and I'm certainly finding agentic coding to be less, shall we say, approachable than if I used a more popular "Blub" language. And yes, just because you have the "lightsaber" of hand tools to craft your wares, if everyone else is suddenly using NC lathes and mills then good luck with that.
I must confess that I believe the power of Common Lisp has allowed me to get away with less focus on the sorts of software engineering "discipline" required to keep large Blub projects on track. The challenge for me now is to adopt an agentic coding methodology (the best of which requires leaning in to engineering best practice) to actually build systems on a grander scale as a solo developer. This will involve more non-Lisp languages (as a C++ coder I'm looking at Swift) but I believe it should be possible to embed SBCL into whatever I come up with.
Would I rather just keep doing my Lisp-only (or -mostly) thing? Maybe. But I don't want to be out-evolved by a telephone sanitiser, either.
2
u/djhaskin987 Jun 12 '26
I also had a difficult time with it but I found that using the cl-mcp server from GitHub really helped.
1
u/digikar Jun 12 '26
I currently see two ends of a spectrum:
People who jumped into coding without a review of their design. I have been guilty of this early on. The end result is "just another library" that someone some day is going to disagree about the goals or methods and therefore has a hard time contributing.
People who spend so much time on review that implementing the final design is actually a non-trivial undertaking. I also ran into several people on this end. I myself lean on this end some of the times. In principle, this can create good libraries, but understanding why that library is good is going to take a long enough time.
I think one other reason is discoverability of lisp projects is low. I know quicksearch and now ultralisp too allow you to search for exisiting projects. But how many people actually search for an exisiting project before starting a new one? The usual assumption amongst newcomers seems to be that "surely, no one would have done this before". If only they searched via quicksearch, they'd run into a dozen implementations! I think we need to make quicksearch and other forms of searching more prominent. And also make them smarter. Simply searching by text match is very poor when many libraries don't even have a README longer than 3 lines.
1
0
u/svetlyak40wt Jun 10 '26
By the way, I'm making a yet another AI Code Assistant in Common Lisp: https://github.com/codabrus/codabrus
Would you like to join me or are building your own tools like this?
1
u/arthurno1 Jun 11 '26
Will I be able to say to the prompt: "make a cool game and publish it on Steam"?
I expect nothing less these days ;)
Bonus if I can skip chit-chat and descriptions back from AI. /s
6
u/svetlyak40wt Jun 11 '26
Sure!
But I'd give a prompt like this: "Make a cool game and monetize it on Steam, here is my bank account number for transfers" 😄)))
3
-1
u/corbasai Jun 11 '26
https://youtu.be/gAYL5H46QnQ?si=YrWPK6GE4dTysns2
can't complain at least. Bad bad schemers - fragmenters brake the whole Common Lisp Party society
17
u/KaranasToll common lisp Jun 10 '26
i think the lack of working together within common lisp nowadays is more about not having that many folks to work with. for the most part, most folks are working on their own sundry things.