Hacker News Reader

Comment by ironmagma | Hacker News Reader

Thanks for the feedback, I have never heard anyone contest the 'Lisp Curse' claim, and mostly the Lisp I've written has been small-time, so this article is not supposed to be about lisps per se, more the business impact of the idea.

But that said, obviously Clojure with deps.edn exists. Looking at Quicklisp's package manager, it looks like the packages are updated on at least a year's interval? That seems quite slow if you are looking to socialize your changes, use someone else's recent bug fix, or to defragment a project.

View on HN

> I have never heard anyone contest the 'Lisp Curse' claim

You could have asked in the community for opinions.

> This is because Lisp makes it very easy to write your own libraries from scratch;

That's not generally true. Some libraries are maintained for decades, since it would be difficult to reproduce them.

The reasons for writing new libraries, instead of an existing one are more like:

* disagreement with coding styles

* very different underlying platform

* need for a different license

* lack of maintainers for code written decades ago

> people who use Lisp tend to do that instead of reusing third-party dependencies.

I don't think that's the case. There are widely used libraries for a bunch of things and having a stable and standardized language makes it actually easier to write platform independent code and enables code sharing.

There are reasons why people write their own libraries, often because existing libraries were written for different platforms (especially the operating system).

In the free software area of Common Lisp, a system like SBCL is popular because of the network effect in a small niche of Lisp programs. Libraries tend to be better supported in SBCL -> more use for SBCL.

> You could have asked in the community for opinions.

True, and I was focused on making a non-Lisp point so I didn't and apologize for that. I do find the feedback valuable although I wonder how to reconcile what's been posted here with what I've heard from other Lisp coders.

Trying not to beat a dead horse, but I recognize there may be many reasons people come up with for writing a new library instead of reusing one. My point is that it has a business impact to do it that way, because unless that library is open-sourced, the next time it happens it will be an overall loss for the industry due to solving the same problem again and again in slightly different ways.

> Trying not to beat a dead horse, but I recognize there may be many reasons people come up with for writing a new library instead of reusing one. My point is that it has a business impact to do it that way, because unless that library is open-sourced, the next time it happens it will be an overall loss for the industry due to solving the same problem again and again in slightly different ways.

One of the reason to use Lisp was to leapfrog the competition. See for example: https://paulgraham.com/avg.html Applications were written in novel areas by small teams. The commercial Lisp vendors had their development environments bought and be used by these teams, but they could not post success stories, because they were not allowed to mention the customer and its application. Here often substantial and complex software had been written, at the core of some new business venture. The reason this software code could not be used by, then was not that it easy to copy, but that the developers did not want to give their competitive advantage away.

For Lisp libraries -> if any library domain gets complex, there will be only a few ones which actually get used, because it was non-trivial to write. People might try to write simpler or new ones, but the better ones are hard to replicate and Lisp developers will tend to use those. For example the Lisp cookbook recommends one Regular Expression library: https://lispcookbook.github.io/cl-cookbook/regexp.html That's what most developer tend to use - it is widely ported, written in good style, well tested, ...

A strange thing in the Common Lisp world is that new developers stumble of old libraries. They expect libraries with lots of bug fixes and a long maintenance log. But the library hasn't much touched in since some years.

They detect then, that this library is "done". It has reached a state where not much needs to be done. This is also an effect of Common Lisp, where the language is mostly stable for several decades and code can be used for a long time without the need for a new attempt.

> they could not post success stories

It feels like Lisp and Open Source are old enough this should not be a relevant concern anymore. Many newer Lisps exist that have been OSS their whole lives, including the community infrastructure. What remains are the inherent properties of the language instead of any legal artifacts.

That is a great set of responses to the Lisp Curse article. Again I will note that my points are not about Lisp as I'm just taking that article as granted (which it turns out it's not, but still). The point about the pareto principle is also language-agnostic, and an interesting point. It's sort of a proof that the 80% problem is going to persist to some extent even if you do use many dependencies. (Note not to the fullest extent — the 80% problem can at least be mitigated by everyone not reimplementing everything every time.)

The Lisp Curse article was written by a web developer with zero Lisp experience in even a hobby setting, let alone professional. He just made it up, like a hallucinating LLM.

> Looking at Quicklisp's package manager, it looks like the packages are updated on at least a year's interval?

I think it used to be closer to monthly. It has slowed down a lot recently. I've seen talk on IRC about ideas on how to improve the bus factor for that situation.

Also, there are some alternatives to Quicklisp that exist, such as ocicl, which seems to be gaining in mindshare. I haven't used it personally (yet), but so far I've only seen positive feedback from people that have tried it.

If there is some Lisp package that has frequent updates that are not picked up via Quicklisp, and you want to keep up with those, then just put the tree of that thing in your project, and refer to its .asd file from yours.

Or just clone into local-projects and quicklisp will load from there.

Or use qlot and drag from many supported source repos.

There are also other sources that are not quicklisp.

Qlot can and does install from github, gitlab, ultralisp, etc.

Reply on news.ycombinator.com