Comment by invalidOrTaken | Hacker News Reader

Comment by invalidOrTaken | Hacker News Reader

I feel for the author and have recently come to a similar (read: not same) conclusion: Lisp is pretty crappy for maybe 90% of the work being done out there. The more easily-accessible and popular a domain is, the worse Lisp will be for it. This isn't because Lisp magically gets worse; it's because other languages get better, through libraries. Even if nine of ten libraries are crappy, there are enough people in the space (remember, it's a popular domain) that something good will come out of it, and eventually everyone will basically settle on a few good choices.

Lisp programmers, when using Lisp for what it's best at, don't use libraries. There are no libraries for what they want to do, because what they're doing is obscure and/or hard.

Lisp is best at doing new things that have never been done before, because it's basically a language for writing libraries. As such, it prospers in unpopular fields.*

This makes it hard for lisp evangelists to be taken seriously. If you're to show someone a hard graphics problem written in lisp vs ruby, your reader has to understand graphics programming first. But calculating primes? Anyone can do that. Which example do you think will get more mindshare?

To summarize: Lisp is great at things you don't hear about.

* One reason Viaweb succeeded using Lisp for the web was because the web was still this exciting frontier and no one had really done anything with it yet. I'd go so far as to say that Viaweb wouldn't succeed today---they'd get trashed by the likes of Weebly, which is written in php for crying out loud.

From what I've seen this role is now played as much, if not more, by languages like Scala and Haskell. Certainly languages like that owe a large debt to Lisp but I'm not so sure what you say is as true of Lisp today as it once was.

I agree and should note that pure functional languages more suited for writing libraries than languages with some first-class functional features. This is so because pureness encourages composability of various parts of program.

The state allows parts of program to communicate through implicit information channel. One part of program could signal another to increment a variable by deleting a file. Or vice versa.

That's why I think Haskell is the best for libraries, Scala less so and Lisp even lesser, even taking into account macro system, code-as-data, etc.

Other languages certainly get better, and many can rely on extensive libraries.

That said, why not try Clojure? Best of both worlds, and then some.

I absolutely adore clojure, and whenever I do a non-sysadmin project on my own, I like to use it.

But I'm still at the point in my career where people hire me rather than the other way around, and all the hand-waving I can do about "superiority of lambda calculus over the state machine" (okay, I'm more clear and practical than that) doesn't convince many.

I think it's more subtle than that. An interesting program usually contains parts that are "easy" (e.g. interfacing with a database) and parts that are "hard" (e.g. complex algorithms). To be productive, you would want to get the easy bits out of the way so you could concentrate on the hard bits.

Making Python or Scala talk to Oracle (for example) is so trivial you can write that bit of your program in no time at all, then get onto the interesting stuff. In Lisp, you have to spend significant time on this trivial stuff. So if you are writing a program on your own PC for your own use, then Lisp is fine. If you are programming anything that is going to run on existing infrastructure or interoperate with other programs, it's very difficult to justify the additional effort of using Lisp.

And I know a bit about this: I wrote Oracle bindings for OCaml! It was fun, sure, but can I justify it when there are already Python bindings? Hmm.

> In Lisp, you have to spend significant time on this trivial stuff. So if you are writing a program on your own PC for your own use, then Lisp is fine. If you are programming anything that is going to run on existing infrastructure or interoperate with other programs, it's very difficult to justify the additional effort of using Lisp.

Remember: Lisp is a family, not a language.

The best counterexample to your claim is: http://clojure.org/

I'd argue even CL covers a lot vs your claim (but please don't make it my arguement, focus on Clojure) with QuickLisp: http://www.quicklisp.org/beta/

Your point is plain to see, and it is correct in principle, but there are plenty of bindings for Lisps too. As far as I understand, making CL talk to Oracle is a battery included in the commercial implementations, or available through CLSQL (and therefore through higher-level libraries built on top of it such as Elephant). Sure, CL may not have all of the latest and greatest, but plenty of languages don't either. While I cannot pretend to approach any sort of "hacker-level" competence in Lisp (I'm not even a programmer really), I have yet to find a relatively trivial task (where my definition of trivial is "included in Python's standard library or a very widely used / de facto standard module", since I'm coming from Python) for which there isn't a usable (and often excellent) Lisp tool. YMMV, of course.

well, if it's a language for writing libraries - why there are no libraries? :)

I think I'm pretty safe saying there are a ton. Every Lisp hacker has their own.

Actually, "library" is probably the wrong word for reused Lisp code. A library is a public thing, an institution---and all that goes with it: slow to change, must be easy to understand, etc.

Instead of libraries, Lisp hackers have private collections. Like a messy desk, they are often supremely useful once you get the hang of it, but are inscrutable to others. Not exactly the best characteristics to get popular on github.

I don't know where you're coming up with this impression at all. Clojure has Leiningen and Maven, Racket has PLaneT, CL has QuickLisp, etc. In my experience Lispers do not waste time solving solved problems.

Certainly Github does not in anyway support your claim: https://github.com/languages/Clojure

popularity, culture and ease of sharing libraries(ex. cpan) for one.

But also its not that its great for writing libraries but that its great for writing libraries that extend the language.

I think that Zach Beane is doing a stupendous job with quicklisp. Of course it's nowhere near CPAN at this stage, but it's a tremendous step forward compared to, say, plain asdf-install.

Reply on news.ycombinator.com