4 ms·

A bit off topic, but is Common Lisp still a good choice? I spent a lot of time learning and coding CL during the last decade. I love lots of things about the l

by nextos 7y ago

A bit off topic, but is Common Lisp still a good choice? I spent a lot of time learning and coding CL during the last decade. I love lots of things about the language. Overall, it's great it's true multiparadigm. Few languages achieve that. However, the implementations are too fragmented which makes the standard quite stagnant. And libraries are falling a bit behind. I love Clasp is putting CL on top of LLVM. I wish we could have something with the best ideas of Racket, Clojure and CL on the LLVM.

earenndil 7y ago
SBCL is a de facto standard, and relying on it is fine. Clasp is nice, but SBCL is fast enough that it's mostly extraneous unless you really need to talk to c++ code.
- peatmoss 7y ago
  I’ve often wondered why SBCL hasn’t been used as the basis for some of the newer lisps and lisp-alikes. It’s performance is pretty great, and is worlds closer to Clojure than the JVM.
  - dang 7y ago
    We've been implementing Arc over SBCL. It's called Clarc. I can't seem to find time to work on it. There's a bit more description here: https://news.ycombinator.com/item?id=21550123 https://news.ycombinator.com/item?id=21550123
  - nextos 7y ago
    Qi and Shen are pretty interesting. Qi compiles to CL, and Shen compiles to a tiny Lisp subset quite easy to port. But Qi license is quite bad. I think Shen adopted BSD, but is still quite niche or close to abandonware.
peatmoss 7y ago
Clojure with a good c (stretch goal: c++) FFI on LLVM would be amazing. I somehow suspect the reason we don’t have it in a fully baked form is that it’s hard. That said, there is Ferret which is Clojure-like, and compiles to c++: https://ferret-lang.org/ https://ferret-lang.org/ Racket is also lovely, and I hope that their port to Chez Scheme will enable alternative implementations, since more of Racket is now written in Racket rather than c.
na85 7y ago
>A bit off topic, but is Common Lisp still a good choice? As always, it depends on your application. For instance I decided recently that I would work my way through the cryptopals challenges, and opted to avoid Lisp since bit-twiddling is such a pain in that language.
- ska 7y ago
  as I recall bit-twiddling isn't actually too painful in common lisp, but certainly is in some other lisps.
- p_l 7y ago
  Since bits are addressable directly in Common Lisp, I found the language to be very very nice for bit twiddling. Maybe you're mixing it up with Clojure? (bit twiddling in clojure without extra libs is a PITA).
Jach 7y ago
Good choices depend heavily on circumstances, so, what are you trying to do, for how long, and with whom? Even if what you're trying to do isn't programming per se, but something like betting on how you'll make programming related money in the future, it matters to specify what exactly it is you're trying to do before you evaluate the choices. I think at least it's hard to argue CL would be a bad choice in general, and it's certainly proved itself over the decades in many domains and circumstances... But there are always tradeoffs, and other languages can be better choices when circumstances push different ones. A particular blog post that gets passed around (you may very well have seen it) is https://www.darkchestnut.com/2017/pragmatic-reasons-for-choosing-common-lisp/ https://www.darkchestnut.com/2017/pragmatic-reasons-for-choo... It's just an example of the process, but it's still valid. His list of requirements might not be your list, or your weighting might be different. (It's been fun reading tweets from https://twitter.com/rainerjoswig https://twitter.com/rainerjoswig this month just to appreciate how portable CL code is across CPU architectures and implementations and if you value that a lot why wouldn't you consider CL very highly; meanwhile others don't value portability and are fine with an effectively iOS-only language or whatever.) I don't really follow your statement about implementations being fragmented --> stagnant standard. The standard is the standard, it's as immutable as C89. Or do you mean you're sad that there's unlikely to be a new revision to the standard that all the implementations will adopt, unlike C99 and beyond (which still isn't fully supported by all the big players)? That's understandable, but you probably used the portable libraries that offer the big things one might want from a new standard, so...
jwr 7y ago
I would say it is not a good choice today, unless you have a legacy code base in CL. There are more modern Lisps which have a much better concurrent programming story — which is why after years of working in Common Lisp I switched to Clojure. The other huge advantage of Clojure is ClojureScript: most of my business logic code these days compiles to both Clojure and ClojureScript, which is important for modern applications and lets me keep my line count low. See my Quora answer (from several years ago, so some things have changed) for more on why I switched: https://www.quora.com/What-do-veteran-Lisp-programmers-think-of-Clojure/answer/Jan-Rychter https://www.quora.com/What-do-veteran-Lisp-programmers-think...
zeveb 7y ago
I think it is. A lot of the 'stagnation' is due to the fact that the standard is a standard, so Lisp implementations aren't changing the definition of characters willy-nilly — and so code written twenty years ago is still correct and performant enough, so there's no need to update it. I would love to see a slightly more modern CL, but it's good enough to get work done, and it's still light-years ahead of everything else.

by nextos 7y ago

earenndil 7y ago

SBCL is a de facto standard, and relying on it is fine. Clasp is nice, but SBCL is fast enough that it's mostly extraneous unless you really need to talk to c++ code.

peatmoss 7y ago
I’ve often wondered why SBCL hasn’t been used as the basis for some of the newer lisps and lisp-alikes. It’s performance is pretty great, and is worlds closer to Clojure than the JVM.
- dang 7y ago
  We've been implementing Arc over SBCL. It's called Clarc. I can't seem to find time to work on it. There's a bit more description here: https://news.ycombinator.com/item?id=21550123 https://news.ycombinator.com/item?id=21550123
- nextos 7y ago
  Qi and Shen are pretty interesting. Qi compiles to CL, and Shen compiles to a tiny Lisp subset quite easy to port. But Qi license is quite bad. I think Shen adopted BSD, but is still quite niche or close to abandonware.

peatmoss 7y ago

Clojure with a good c (stretch goal: c++) FFI on LLVM would be amazing. I somehow suspect the reason we don’t have it in a fully baked form is that it’s hard. That said, there is Ferret which is Clojure-like, and compiles to c++: https://ferret-lang.org/ https://ferret-lang.org/ Racket is also lovely, and I hope that their port to Chez Scheme will enable alternative implementations, since more of Racket is now written in Racket rather than c.

na85 7y ago

>A bit off topic, but is Common Lisp still a good choice? As always, it depends on your application. For instance I decided recently that I would work my way through the cryptopals challenges, and opted to avoid Lisp since bit-twiddling is such a pain in that language.

ska 7y ago
as I recall bit-twiddling isn't actually too painful in common lisp, but certainly is in some other lisps.
p_l 7y ago
Since bits are addressable directly in Common Lisp, I found the language to be very very nice for bit twiddling. Maybe you're mixing it up with Clojure? (bit twiddling in clojure without extra libs is a PITA).

Jach 7y ago

Good choices depend heavily on circumstances, so, what are you trying to do, for how long, and with whom? Even if what you're trying to do isn't programming per se, but something like betting on how you'll make programming related money in the future, it matters to specify what exactly it is you're trying to do before you evaluate the choices. I think at least it's hard to argue CL would be a bad choice in general, and it's certainly proved itself over the decades in many domains and circumstances... But there are always tradeoffs, and other languages can be better choices when circumstances push different ones. A particular blog post that gets passed around (you may very well have seen it) is https://www.darkchestnut.com/2017/pragmatic-reasons-for-choosing-common-lisp/ https://www.darkchestnut.com/2017/pragmatic-reasons-for-choo... It's just an example of the process, but it's still valid. His list of requirements might not be your list, or your weighting might be different. (It's been fun reading tweets from https://twitter.com/rainerjoswig https://twitter.com/rainerjoswig this month just to appreciate how portable CL code is across CPU architectures and implementations and if you value that a lot why wouldn't you consider CL very highly; meanwhile others don't value portability and are fine with an effectively iOS-only language or whatever.) I don't really follow your statement about implementations being fragmented --> stagnant standard. The standard is the standard, it's as immutable as C89. Or do you mean you're sad that there's unlikely to be a new revision to the standard that all the implementations will adopt, unlike C99 and beyond (which still isn't fully supported by all the big players)? That's understandable, but you probably used the portable libraries that offer the big things one might want from a new standard, so...

jwr 7y ago

I would say it is not a good choice today, unless you have a legacy code base in CL. There are more modern Lisps which have a much better concurrent programming story — which is why after years of working in Common Lisp I switched to Clojure. The other huge advantage of Clojure is ClojureScript: most of my business logic code these days compiles to both Clojure and ClojureScript, which is important for modern applications and lets me keep my line count low. See my Quora answer (from several years ago, so some things have changed) for more on why I switched: https://www.quora.com/What-do-veteran-Lisp-programmers-think-of-Clojure/answer/Jan-Rychter https://www.quora.com/What-do-veteran-Lisp-programmers-think...

zeveb 7y ago

I think it is. A lot of the 'stagnation' is due to the fact that the standard is a standard, so Lisp implementations aren't changing the definition of characters willy-nilly — and so code written twenty years ago is still correct and performant enough, so there's no need to update it. I would love to see a slightly more modern CL, but it's good enough to get work done, and it's still light-years ahead of everything else.