3 ms·

> 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 wr

by 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.
  - ironmagma 2y ago
    > 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.)

by lispm 2y ago

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.
- ironmagma 2y ago
  > 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.)