Hacker News Reader

Comment by didibus | Hacker News Reader

I'd say pros:

  - Compiles to native
  - Superior REPL experience/interactivity
  - Easier C FFI

I'd say cons:

  - Smaller ecosystem, not as many libraries.
  - Dated tooling.
  - Inferior support for multi-threading/multi-core.
  - Not as homoiconic. Only lists are by default.
  - Standard is abandoned. No new versions since 1994. Some CDRs till 2013.

Neutral:

  - Leans towards OOP and imperative mutability over Functional and immutable. 
  - Doesn't have unified abstractions over datastructures.

View on HN

Common Lisp compiles to much more than just 'native'. Like C, LLVM, DLLs, ... and a has a bunch of exotic stuff like whole-program-to-C compilers, Common Lisp on the metal or Common Lisp on top of Prolog https://github.com/TeamSPoon/wam_common_lisp .

Common Lisp also has full language interpreters: these are implementations of Common Lisp which interpret s-expression level code - not byte code.

Common Lisp can easily dump images and make them executable. Saving and starting them is quick.

Common Lisp has implementations mostly written in Common Lisp - including the compiler and large parts of the runtime.

Is this point of your parent commenter right?

> - Not as homoiconic. Only lists are by default.

I read that, too. But I'm not sure what he means by 'Only lists are by default'. If he means that only lists have a literal representation, then it would be slightly wrong - since Common Lisp has literal representations for various numbers, symbols, characters, strings, vectors, arrays, structures, pathnames, ...

Plus the s-expression syntax is user-extensible - making it as 'homoiconic' as the user needs it.

Interesting, thanks.

I'm referring to the fact that Common Lisp does not have a map and set literal by default. It has a lot of homoiconic literals, and is still very homoiconic. And Common Lisp's reader and printer can be extended by the user to add them back in non standard ways. I still personally consider it as a slight cons against Clojure.

Where do you get the "inferior support for multi-threading/multi-core" from? SBCL and ClozureCL (among others) support both with no issues.

Dated tooling? Not if you compare it to Clojure tooling, SLIME is lightyears ahead in terms of robustness. I've lost track of the Clojure REPLs (nrepl, CIDER, inf-clojure, ...) that still suck.

Re: "smaller ecosystem, not as many libraries", surely you are joking or not at all aware of things like the CMU Common Lisp repository. If we disregard Java libraries, Clojure doesn't even come close to CL code that has been made available over the last few _decades_.

One doesn't need CDRs or another (expensive, time consuming) standardization process when there are great portability libraries (FFI, threads, sockets, convenience macros, ..) or one can pick a defacto standard implementation that offers all of the above.

>I'd say cons:

I'll raise you a car.

I would add "- Better stack traces" to the pros.

Reply on news.ycombinator.com