4 ms·

We have a fantastic Common Lisp package ecosystem with Quicklisp and we use other people's libraries all the time. Most of us are savvy enough to share our 80%

We have a fantastic Common Lisp package ecosystem with Quicklisp and we use other people's libraries all the time. Most of us are savvy enough to share our 80% solutions so that others can add their 20%. I wish more people would realize that the Common Lisp we program in today is not your Grandma's Common Lisp. Lisp usage and culture change over time just like in every other language ecosystem. I never see my Lisp reflected in these tired tropes.

ironmagma 2y ago
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.
- kazinator 2y ago
  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.
- kazinator 2y ago
  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.
  - trocado 2y ago
    Or just clone into local-projects and quicklisp will load from there.
    - ungamedplayer 2y ago
      Or use qlot and drag from many supported source repos.
- lispm 2y ago
  > 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.
  - ironmagma 2y ago
    > 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.
    - lispm 2y ago
      > 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 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 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.
- kagevf 2y ago
  > 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.
- ungamedplayer 2y ago
  There are also other sources that are not quicklisp. Qlot can and does install from github, gitlab, ultralisp, etc.
deleted 2y ago
[deleted]
ReleaseCandidat 2y ago
> Quicklisp [...] not your Grandma's Common Lisp. Ocicl, if we are not talking about your Mother's Common Lisp ;) https://github.com/ocicl/ocicl https://github.com/ocicl/ocicl
- corinroyal 2y ago
  I love it! My grandma was a "computer" who held patents on coax connectors and kept some early CAD mainframes alive. Can't wait to try OSICL.

ironmagma 2y ago

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.

kazinator 2y ago
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.
kazinator 2y ago
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.
- trocado 2y ago
  Or just clone into local-projects and quicklisp will load from there.
  - ungamedplayer 2y ago
    Or use qlot and drag from many supported source repos.
lispm 2y ago
> 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.
- ironmagma 2y ago
  > 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.
  - lispm 2y ago
    > 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 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 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.
kagevf 2y ago
> 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.
ungamedplayer 2y ago
There are also other sources that are not quicklisp. Qlot can and does install from github, gitlab, ultralisp, etc.

deleted 2y ago

[deleted]

ReleaseCandidat 2y ago

> Quicklisp [...] not your Grandma's Common Lisp. Ocicl, if we are not talking about your Mother's Common Lisp ;) https://github.com/ocicl/ocicl https://github.com/ocicl/ocicl

corinroyal 2y ago
I love it! My grandma was a "computer" who held patents on coax connectors and kept some early CAD mainframes alive. Can't wait to try OSICL.