Comment by jorams | Hacker News Reader

Comment by jorams | Hacker News Reader

The author almost immediately writes off Common Lisp for lack of "frictionless access to a rich ecosystem of code written in the same language as your software", then recommends Clojure. Most of the ecosystem you have access to in Clojure is, in fact, not built in Clojure, and most Clojure libraries were/are wrappers around Java or Javascript.

Footnote 1 makes no sense, suggesting that the only way to get access to "a bunch of other useful code" is to embed it into a C program and that understanding your dependencies is somehow easier in Javascript.

In reality, Quicklisp[1] offers effortless access to over 1200 libraries and programs. It's nowhere near the 200 thousand packages in npm, but the overall quality is good and these libraries cover a surprisingly large number of things.

The post tries to display Clojure as "Lisp, but with access to open source". Clojure is a fine programming language, but it's also completely different from Common Lisp. CL has high quality optimizing compilers performing extensive type checking, a powerful object system, easy access to C libraries, etc. If you need Java interop, you can just use ABCL[2].

[1]: https://www.quicklisp.org/ [2]: http://abcl.org/

Seeing Common Lisp fans arguing against Clojure fans is funny since your market share combined is insignificant compared with the mainstream choices. You should learn from each other and grow that pie together.

I also don't agree with you. Intuitively Lisp might be a secret weapon for startups, but not for open source where the communities of the mainstream choices are more productive, simply because of popularity. Java is a huge ecosystem of working and mature solutions. If you don't depend on Java, you depend on C. And for the kind of problems Lisp is suited for, I'd rather take Java. You're also missing the point on JavaScript. Say what you will about the quality of npm packages, but ClojureScript can reach people that your favorite CLisp cannot, due to the browser.

Also you can't seriously recommend ABCL.

Please avoid referring to the language as "CLisp". It's Common Lisp or just CL, of which GNU CLISP[1] is but a single implementation.

[1] http://www.clisp.org/

  > Intuitively Lisp might be a secret weapon for startups, but not for open source 
  > where the communities of the mainstream choices are more productive, simply because
  > of popularity

Open source is not a popularity contest. In fact, open source, and specially free and libre software, is a great place for leftfield technologies to flourish. In fact, Lisp had a place in free software before Github even existed, with various flavours being the scripting language of choice in popular projects like Emacs, Gimp or Gnome.

It is rather in the proprietary corporate world where there is often resistance to adopt languages outside of the mainstream. The more supply of developers for a technology is available, the lower cost of labour. It's hard for the merits of a technology to argue against this fact in the face of management.

Nobody who uses it really likes Emacs list and Guile didn't get far. Not the best success stories to give.

> Say what you will about the quality of npm packages, but ClojureScript can reach people that your favorite CLisp cannot, due to the browser.

There's always ParenScript: https://common-lisp.net/project/parenscript/

That 200k figure isn't very comparable to other languages either as there are a lot of pacakages that just do a tiny thing and a hell if a lot of overlap in packages.

While that's got upsides I must admit I prefer one or two relatively complete and stable packages over way more numerically but leas stable complete packages.

But I come from a desktop background so I'm spoilt in that regard I guess.

I view every additional depency as a weakness a year from now.

Completely agree. Maintaining a node project is a nightmare job if you rely on any more than a trivial number of packages. The ecosystem is quicksand.

More akin to standing in quick sand while someone sets you fire and a succession of literal band wagons drives past ;).

I love Common Lisp, and as you say, there are many outstanding libraries that Quicklisp gives you easy access to. ABCL hasn't been "marketed" enough to the Java community, so it has less mind share. When I last looked at ABCL the Java interop was not as clean as Clojure's, so while it was there it felt more clunky. This was at least a year ago, so things are probably better.

I use Clojure to implement a portion of a semantic search engine: it is packaged as a REST servlet that responds to requests from a medical POC application. Because of the Java interop I utilize our internal libraries and from the ops perspective they are just deploying a WAR file that plays nicely in their reporting infrastructure.

I've been using Clojure since its first release and am comfortable with it and its ecosystem. ABCL is a contender, but I have yet to do a performance comparison, both for native and interop tests. And in reality the only part of Common Lisp I really miss is the condition system. Clojure as an implementation of CL's format and I was never a big user of loop, so...

Good point, thanks! I've removed the footnote, and I'm going to rewrite that paragraph to steer away from Common Lisp a bit.

My point wasn't Clojure > Common Lisp. I was simply anticipating the "but npm has 200k modules" argument against Lisps in general and I wanted to illustrate why it doesn't matter if you're using Clojure.

It does seem like a somewhat valid case against Common Lisp, but I don't care and it detracts from my main point.

> It's nowhere near the 200 thousand packages in npm

It's also nowhere near the massive FOSS ecosystem that runs on the JVM.

Agreed, I wish people stop selling the JVM/JS libs as the solution to all Clojure library needs, is not really smooth sailing as most paint it out to be.

Reply on news.ycombinator.com