Pragmatic reasons for choosing Common Lisp (2017)

darkchestnut.com

18 points·gibsonf1··5 comments

Sometimes I see articles with tables and decision trees regarding language choice. I find it funny, because if I was doing any old thing, I'd use $typical_lang, and if I was writing a script, I'd use bash-and-not-python-because-I-don't-know-python. If I craved novelty, I'd use $not_blub.

If I thought everyone was like me, I'd joke at this author, "Come on. You wanted to use CL and you needed justification." But I suppose there are people who are not like me, who decide how this author decides.

Ok I'll take my own bait: Why not Java? Depite not compiling to a native executable, It'll be faster than Ruby, Python, and Scheme. Deployment is a jar file. More than adequate GUI tools. As regards language stability, the language committee is conservative. To me, the answer is, "Because the author already knows Ruby, Python, Scheme, and Common Lisp, and already-knowing a language is huge." But of course: I'm baiting because I'm projecting : ).

Or why not Haskell?

To be clear, the more unusual case is the author knowing none of the languages he evaluated. In that case I think the case for Java (and even Haskell) is very strong.

Or at the very least, why not Clojure? I'm unaware of any advantage CL has over it at this point.

A wide variety of implementations

Performance

save-lisp-and-die

CLOS

LOOP

Conditions system

If you need to build what Hickey calls a "situated program", Clojure is a great choice, but that's not the only type of environment we need to run programs.

You should look into CLOS though. It will really impact the way you code Lisp. Even those that will never code in Lisp can benefit from looking into its approach to object paradigms.

Reply on news.ycombinator.com