22 ms·

No way. The ecosystem is just not there. All the libraries - both open source and commercial that do a million things - do not exist in the Lisp ecosystem. Ev

No way. The ecosystem is just not there. All the libraries - both open source and commercial that do a million things - do not exist in the Lisp ecosystem. Even in 2000

lisper 5y ago
Actually they pretty much do, much more so now than in 2000. QuickLisp has been a real game-changer.
- nabla9 5y ago
  How many of those 1500 QuickLisp libraries work together without extra work? I seriously tried to use Common Lisp for numerical programming 10 years ago. It was faster and would have been better platform for numerical programming than Python, R or Julia. Just a great language. (Ross Ihaka had plans to port R into Common Lisp to make R fast at one point) The real problem was the lack of convergence of data structures and conventions above the language standard. Python has pandas tables and numpy arrays. R has Data frame. Every numerical library for CL had their own conventions, and ways to implement the basic data structure, Some used lists, some just arrays, some had list of vectors, classes, structs, property lists. The impedance mismatch was not worth it. Either implement numpy equivalent on your own or half of your code is data massaging data between libraries. -- Perlis epigram: "9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."
  - varjag 5y ago
    > How many of those 1500 QuickLisp libraries work together without extra work? I'm not sure what kind of question is that. A whole bunch of them? Certainly not worse ratio than many contemporary or even modern languages. There's a lot less friction to get any random GitHub CL project working than say a Swift one.
    - nabla9 5y ago
      > Certainly not worse ratio than many contemporary or even modern languages CL has no standardized extensible abstraction classes for basic collection types. Almost all languages have that because it's so essential for communicating between libraries. I'm relatively sure Swift has one Only other language similar to CL in this regard is C. And you can't ask if what you have is mapping of symbol number pairs. CL has multiple libraries that fix this problem but no significant convergence has emerged. For simple key value pairs or maps you must keep track and convert between ;; property list (implicit type) (type-of '(foo 1 bar 2 baz 3)) => CONS ;; assoc-list (implicit type) (type-of '((foo . 1) (bar . 2) (baz . 3))) => CONS ;; list of lists (implicit type) (type-of '((foo 1) (bar 2) (baz 3))) => CONS ;; hash-table (explicit only about being hash table) (type-of #<HASH-TABLE :TEST EQL :COUNT 3 {10018A8023}>) => HASH-TABLE)
  - dreamcompiler 5y ago
    >Either implement numpy equivalent on your own or half of your code is data massaging data between libraries I haven't tested this but here you go: https://github.com/numcl/numcl https://github.com/numcl/numcl
  - jhgb 5y ago
    > How many of those 1500 QuickLisp libraries work together without extra work? I'm pretty sure that due to the curated nature of code in QuickLisp, there's really no problem with that. If something doesn't load properly, it's a bug that you should report.
antonvs 5y ago
The year after he wrote this, Norvig joined Google and decided that Python was a good enough alternative. He posted a web page about it, but I can't find it rn. However, here's a comment of his on HN about it: https://news.ycombinator.com/item?id=1803815 https://news.ycombinator.com/item?id=1803815
- Jtsummers 5y ago
  https://norvig.com/python-lisp.html https://norvig.com/python-lisp.html This essay starts with the context of his choosing Python to express what was formerly pseudocode.
- Rerarom 5y ago
  Also see this, in the same topic but not in the same thread: https://news.ycombinator.com/item?id=1803627 https://news.ycombinator.com/item?id=1803627
- vindarel 5y ago
  but Python doesn't resemble Lisp at all: https://lisp-journey.gitlab.io/pythonvslisp/ https://lisp-journey.gitlab.io/pythonvslisp/ (overview of the workflows and ecosystems)
dimitar 5y ago
Now you have Clojure which runs on the JVM and interops nicely
- elwell 5y ago
  And ClojureScript to interop with JS ecosystem.
- Scarbutt 5y ago
  I wouldn't call it "nicely", there is lot of stuff that makes it really tedious. The bigger issue though is wasting time wrapping Java libraries and most comments I see about Clojure interop talk as if there is no cost to it. Clojure has good foundations but the ecosystem never really developed.
  - finalfantasia 5y ago
    > The bigger issue though is wasting time wrapping Java libraries and most comments I see about Clojure interop talk as if there is no cost to it. You are not forced to "waste time" wrapping Java libraries. As a matter of fact, thanks to the interop features that are well thought out, using Java libraries directly via the interop is encouraged and preferred to wrappers (Java Time API is a good example.) You may _choose_ to write wrappers for Java libraries if they make consuming these libraries in your code a bit nicer. > Clojure has good foundations but the ecosystem never really developed. There's no separate ecosystem for Clojure(Script). The established ecosystems such as JVM, .NET, and JavaScript _are_ the Clojure ecosystem. The creator of Clojure(Script) realized that it would be practically impossible to build an ecosystem from scratch without significant investment (Sun spent billions of marketing dollars alone in Java) and thus deliberately chose to make Clojure(Script) a language hosted on well-developed platforms such as JVM, .NET, and JavaScript. Also because of this focus on being a hosted language, he went to great lengths to ensure the interop with its hosting platforms is as seamless as possible. If you need an example for awkward interop with Java, try Scala.
  - dimitar 5y ago
    You are not forced by the language to wrap libraries. In fact "Programming Clojure" by some of the authors says the following: "Clojure embraces java and its libraries. Idiomatic Clojure code calls Java libraries directly and doesn't try to wrap everything under the sun to look like Lisp. This surprises make new Clojure developers but is very pragmatic. Where Java isn't broken, Clojure doesn't fix it" So the ecosystem is a superset of the Java and JS ecosystems, which are pretty developed. I do agree that the cost of required to know 2 or 3 languages is real though.
eatonphil 5y ago
Armed Bear Common Lisp (Common Lisp on the JVM) may be the most obvious choice if you prioritize ecosystem above all else (which isn't a bad thing). https://abcl.org/trac/ https://abcl.org/trac/
dreamcompiler 5y ago
The philosophy of Lisp encourages writing your own libraries because it's so easy to do. You're expected to know how to program if you use Lisp; not to depend on tiny prewritten functions in the npm universe that may or may not solve your problem, that may or may not be written in a secure or efficient fashion, and that possibly pull in a million transitive dependencies you don't need. That said, Common Lisp itself includes many of the more useful but difficult-to-write features like hash tables, sort/merge, bignums, complex numbers, etc. The most-used stuff that's not in Common Lisp itself like multithreading and sockets are well-covered by external libraries. The lesser-needed stuff is also quite well covered by the quicklisp library infrastructure [0] as well. So the statement "libraries...do not exist in the Lisp ecosystem" is plainly false and it marks the speaker as someone not very familiar with Lisp. [0] https://www.quicklisp.org/beta/releases.html https://www.quicklisp.org/beta/releases.html
- throw_m239339 5y ago
  > The philosophy of Lisp encourages writing your own libraries because it's so easy to do That statement could be said of any language the programmer is comfortable with. It's no more a LISP philosophy than a C++ one. The difference is that way more people are working with C++ (or Java) thus opensourcing their libraries for others to be used.
  - jhgb 5y ago
    I think the argument there was that lots of things were so much easier to do in Lisp that people wrote their own implementation, then they thought "what's the big deal about it?", and then they didn't share their library because they didn't think they've accomplished something meaningful to share. So you end up with people doing things in C++ and Java and publishing it and getting their code reused because 1) the authors of the code were more likely to think of publishing their code as a useful thing, and 2) due to some things being harder in those languages, other people were more likely to shop for libraries rather than to think "I can do this myself".
- AnimalMuppet 5y ago
  Sure, libraries exist in Lisp. The claim that they don't was a fairly ridiculous statement. But... Do libraries exist in Lisp on the same scale as they exist in Java? Especially, do they exist with the same level of quality, professionalism, and maintenance as they exist in Java? I'm guessing that the answer is no.
agumonkey 5y ago
There was an article in the 2000s from a dude looking at a graph library, java had 3 major players, non of them did what he needed (generics issues or similar). He ended up rolling his own. Things are not so simple
gumby 5y ago
So true, but this class of comment always amuses me as in the 1980s one of the (many) criticisms leveled at Common Lisp was that its library support was too big.
lmilcin 5y ago
The ecosystem is a function of popularity. Lisp isn't very popular because, at least in my opinion, it requires a relatively high level of maturity and experience to be used effectively on nontrivial projects. Every single project in Lisp (Common Lisp, Clojure) that I have observed ended in a disaster mostly because developers could not figure out what the strengths of Lisp are to realize the benefits and then killed themselves with too much freedom. Absent large enough number of success stories companies will default on Java because it is good enough language to be able to effectively realize typical enterprise application and dumb enough to be used by a beginner dev, even at the cost of boilerplate. At least that's the official story. It is really difficult to explain to business that you could do whatever they want with 1/5th or 1/50th of the amount of code if you just used a good language for it.
- coliveira 5y ago
  I think it is a matter of education. Software developers learn to program in traditional languages, and Lisp is just an add on. So they really don't know how to use Lisp well. Languages like Python and Java benefit from all the formal education programmers have received in the concepts they use.
  - mypalmike 5y ago
    I think it's more fundamental than that. Reading and writing Lisp means turning your brain into an AST analyzer. Some programmers love this. Most don't.
    - pjmlp 5y ago
      Yeah although changing from print(x) to (print x) isn't that much of a deal. Where I saw fellow university friends having a problem was with thinking in Prolog and computational logic.
      - mypalmike 5y ago
        You're right - at the single element level it's not that different. But the overall effect is very different. For instance, simple ergonomic things that help programmers read code, like the word "else" in an if statement/expression are elided because its AST is implicit in its position in Lisp. Similarly, you can't quickly scan a page of code for something like "=" to see what's getting assigned - you have to look for let pairs. And even then, making local variables seems to be considered wasteful in Lisp if there's a way to structure it so that the value can be placed somehow directly into the AST as the evaluation of an expression. The result is that most Lisp code I've seen has a rigidity to it of deep expressions within expressions. Deep expressions are certainly possible to implement in other languages, but it's rare to see it done so thoroughly as Lisp developers seem to enjoy doing. The result is "hard to read" in the sense that it's harder to scan syntactically (lisp having essentially no syntax) and harder to modify due to the carefully constructed expression nesting. These may both be seen as my own shortcomings wrt the language, but I think many others share them.
vindarel 5y ago
https://github.com/CodyReichert/awesome-cl https://github.com/CodyReichert/awesome-cl there are less than in Java-land but there might be more than you think. And there are options for the rest.

No way. The ecosystem is just not there. All the libraries - both open source and commercial that do a million things - do not exist in the Lisp ecosystem. Even in 2000

lisper 5y ago

Actually they pretty much do, much more so now than in 2000. QuickLisp has been a real game-changer.

nabla9 5y ago
How many of those 1500 QuickLisp libraries work together without extra work? I seriously tried to use Common Lisp for numerical programming 10 years ago. It was faster and would have been better platform for numerical programming than Python, R or Julia. Just a great language. (Ross Ihaka had plans to port R into Common Lisp to make R fast at one point) The real problem was the lack of convergence of data structures and conventions above the language standard. Python has pandas tables and numpy arrays. R has Data frame. Every numerical library for CL had their own conventions, and ways to implement the basic data structure, Some used lists, some just arrays, some had list of vectors, classes, structs, property lists. The impedance mismatch was not worth it. Either implement numpy equivalent on your own or half of your code is data massaging data between libraries. -- Perlis epigram: "9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."
- varjag 5y ago
  > How many of those 1500 QuickLisp libraries work together without extra work? I'm not sure what kind of question is that. A whole bunch of them? Certainly not worse ratio than many contemporary or even modern languages. There's a lot less friction to get any random GitHub CL project working than say a Swift one.
  - nabla9 5y ago
    > Certainly not worse ratio than many contemporary or even modern languages CL has no standardized extensible abstraction classes for basic collection types. Almost all languages have that because it's so essential for communicating between libraries. I'm relatively sure Swift has one Only other language similar to CL in this regard is C. And you can't ask if what you have is mapping of symbol number pairs. CL has multiple libraries that fix this problem but no significant convergence has emerged. For simple key value pairs or maps you must keep track and convert between ;; property list (implicit type) (type-of '(foo 1 bar 2 baz 3)) => CONS ;; assoc-list (implicit type) (type-of '((foo . 1) (bar . 2) (baz . 3))) => CONS ;; list of lists (implicit type) (type-of '((foo 1) (bar 2) (baz 3))) => CONS ;; hash-table (explicit only about being hash table) (type-of #<HASH-TABLE :TEST EQL :COUNT 3 {10018A8023}>) => HASH-TABLE)
- dreamcompiler 5y ago
  >Either implement numpy equivalent on your own or half of your code is data massaging data between libraries I haven't tested this but here you go: https://github.com/numcl/numcl https://github.com/numcl/numcl
- jhgb 5y ago
  > How many of those 1500 QuickLisp libraries work together without extra work? I'm pretty sure that due to the curated nature of code in QuickLisp, there's really no problem with that. If something doesn't load properly, it's a bug that you should report.

antonvs 5y ago

The year after he wrote this, Norvig joined Google and decided that Python was a good enough alternative. He posted a web page about it, but I can't find it rn. However, here's a comment of his on HN about it: https://news.ycombinator.com/item?id=1803815 https://news.ycombinator.com/item?id=1803815

Jtsummers 5y ago
https://norvig.com/python-lisp.html https://norvig.com/python-lisp.html This essay starts with the context of his choosing Python to express what was formerly pseudocode.
Rerarom 5y ago
Also see this, in the same topic but not in the same thread: https://news.ycombinator.com/item?id=1803627 https://news.ycombinator.com/item?id=1803627
vindarel 5y ago
but Python doesn't resemble Lisp at all: https://lisp-journey.gitlab.io/pythonvslisp/ https://lisp-journey.gitlab.io/pythonvslisp/ (overview of the workflows and ecosystems)

dimitar 5y ago

Now you have Clojure which runs on the JVM and interops nicely

elwell 5y ago
And ClojureScript to interop with JS ecosystem.
Scarbutt 5y ago
I wouldn't call it "nicely", there is lot of stuff that makes it really tedious. The bigger issue though is wasting time wrapping Java libraries and most comments I see about Clojure interop talk as if there is no cost to it. Clojure has good foundations but the ecosystem never really developed.
- finalfantasia 5y ago
  > The bigger issue though is wasting time wrapping Java libraries and most comments I see about Clojure interop talk as if there is no cost to it. You are not forced to "waste time" wrapping Java libraries. As a matter of fact, thanks to the interop features that are well thought out, using Java libraries directly via the interop is encouraged and preferred to wrappers (Java Time API is a good example.) You may _choose_ to write wrappers for Java libraries if they make consuming these libraries in your code a bit nicer. > Clojure has good foundations but the ecosystem never really developed. There's no separate ecosystem for Clojure(Script). The established ecosystems such as JVM, .NET, and JavaScript _are_ the Clojure ecosystem. The creator of Clojure(Script) realized that it would be practically impossible to build an ecosystem from scratch without significant investment (Sun spent billions of marketing dollars alone in Java) and thus deliberately chose to make Clojure(Script) a language hosted on well-developed platforms such as JVM, .NET, and JavaScript. Also because of this focus on being a hosted language, he went to great lengths to ensure the interop with its hosting platforms is as seamless as possible. If you need an example for awkward interop with Java, try Scala.
- dimitar 5y ago
  You are not forced by the language to wrap libraries. In fact "Programming Clojure" by some of the authors says the following: "Clojure embraces java and its libraries. Idiomatic Clojure code calls Java libraries directly and doesn't try to wrap everything under the sun to look like Lisp. This surprises make new Clojure developers but is very pragmatic. Where Java isn't broken, Clojure doesn't fix it" So the ecosystem is a superset of the Java and JS ecosystems, which are pretty developed. I do agree that the cost of required to know 2 or 3 languages is real though.

eatonphil 5y ago

Armed Bear Common Lisp (Common Lisp on the JVM) may be the most obvious choice if you prioritize ecosystem above all else (which isn't a bad thing). https://abcl.org/trac/ https://abcl.org/trac/

dreamcompiler 5y ago

The philosophy of Lisp encourages writing your own libraries because it's so easy to do. You're expected to know how to program if you use Lisp; not to depend on tiny prewritten functions in the npm universe that may or may not solve your problem, that may or may not be written in a secure or efficient fashion, and that possibly pull in a million transitive dependencies you don't need. That said, Common Lisp itself includes many of the more useful but difficult-to-write features like hash tables, sort/merge, bignums, complex numbers, etc. The most-used stuff that's not in Common Lisp itself like multithreading and sockets are well-covered by external libraries. The lesser-needed stuff is also quite well covered by the quicklisp library infrastructure [0] as well. So the statement "libraries...do not exist in the Lisp ecosystem" is plainly false and it marks the speaker as someone not very familiar with Lisp. [0] https://www.quicklisp.org/beta/releases.html https://www.quicklisp.org/beta/releases.html

throw_m239339 5y ago
> The philosophy of Lisp encourages writing your own libraries because it's so easy to do That statement could be said of any language the programmer is comfortable with. It's no more a LISP philosophy than a C++ one. The difference is that way more people are working with C++ (or Java) thus opensourcing their libraries for others to be used.
- jhgb 5y ago
  I think the argument there was that lots of things were so much easier to do in Lisp that people wrote their own implementation, then they thought "what's the big deal about it?", and then they didn't share their library because they didn't think they've accomplished something meaningful to share. So you end up with people doing things in C++ and Java and publishing it and getting their code reused because 1) the authors of the code were more likely to think of publishing their code as a useful thing, and 2) due to some things being harder in those languages, other people were more likely to shop for libraries rather than to think "I can do this myself".
AnimalMuppet 5y ago
Sure, libraries exist in Lisp. The claim that they don't was a fairly ridiculous statement. But... Do libraries exist in Lisp on the same scale as they exist in Java? Especially, do they exist with the same level of quality, professionalism, and maintenance as they exist in Java? I'm guessing that the answer is no.

agumonkey 5y ago

There was an article in the 2000s from a dude looking at a graph library, java had 3 major players, non of them did what he needed (generics issues or similar). He ended up rolling his own. Things are not so simple

gumby 5y ago

So true, but this class of comment always amuses me as in the 1980s one of the (many) criticisms leveled at Common Lisp was that its library support was too big.

lmilcin 5y ago

The ecosystem is a function of popularity. Lisp isn't very popular because, at least in my opinion, it requires a relatively high level of maturity and experience to be used effectively on nontrivial projects. Every single project in Lisp (Common Lisp, Clojure) that I have observed ended in a disaster mostly because developers could not figure out what the strengths of Lisp are to realize the benefits and then killed themselves with too much freedom. Absent large enough number of success stories companies will default on Java because it is good enough language to be able to effectively realize typical enterprise application and dumb enough to be used by a beginner dev, even at the cost of boilerplate. At least that's the official story. It is really difficult to explain to business that you could do whatever they want with 1/5th or 1/50th of the amount of code if you just used a good language for it.

coliveira 5y ago
I think it is a matter of education. Software developers learn to program in traditional languages, and Lisp is just an add on. So they really don't know how to use Lisp well. Languages like Python and Java benefit from all the formal education programmers have received in the concepts they use.
- mypalmike 5y ago
  I think it's more fundamental than that. Reading and writing Lisp means turning your brain into an AST analyzer. Some programmers love this. Most don't.
  - pjmlp 5y ago
    Yeah although changing from print(x) to (print x) isn't that much of a deal. Where I saw fellow university friends having a problem was with thinking in Prolog and computational logic.
    - mypalmike 5y ago
      You're right - at the single element level it's not that different. But the overall effect is very different. For instance, simple ergonomic things that help programmers read code, like the word "else" in an if statement/expression are elided because its AST is implicit in its position in Lisp. Similarly, you can't quickly scan a page of code for something like "=" to see what's getting assigned - you have to look for let pairs. And even then, making local variables seems to be considered wasteful in Lisp if there's a way to structure it so that the value can be placed somehow directly into the AST as the evaluation of an expression. The result is that most Lisp code I've seen has a rigidity to it of deep expressions within expressions. Deep expressions are certainly possible to implement in other languages, but it's rare to see it done so thoroughly as Lisp developers seem to enjoy doing. The result is "hard to read" in the sense that it's harder to scan syntactically (lisp having essentially no syntax) and harder to modify due to the carefully constructed expression nesting. These may both be seen as my own shortcomings wrt the language, but I think many others share them.

vindarel 5y ago

https://github.com/CodyReichert/awesome-cl https://github.com/CodyReichert/awesome-cl there are less than in Java-land but there might be more than you think. And there are options for the rest.