4 ms·

>Common Lisp is just too "hardcore" for pragmatic use, in my opinion. In what ways? Asking as Lisp newbie.

bmitc 3y ago
It's mainly that the core editor is Emacs or proprietary ones that have indeterminate futures, there are different implementations that are incompatible for things not defined in the standard, such as for GUIs, not a well defined and vibrant ecosystem or community, the package system is strange, and other things of this nature. As a language, I think it has a bit of cruft from being a mismash of everyone's favorite features from all the Lisps around the time that the standard was created. I find that it is hard to read, and this is coming from someone who likes Schemes and doesn't care about parentheses. Furthermore, you will struggle finding a job. Although admittedly, the jobs you do find may be cool. But they may also be giant balls of mud, which is my main impression and true from what I have read. I think for personal or dedicated use cases within a larger system it is probably awesome. For example, I believe the CLR (.NET) garbage collector was generated via Common Lisp code. I personally use other languages for my personal projects, namely F# and Elixir, and when I want to reach for a Lisp/Scheme, I choose Racket. I find Scheme a more focused language. I don't think I'll ever have the time to actually understand things like CLOS and the metaobject protocol in Common Lisp. The condition system seems pretty cool. I have practically every Lisp book there is, and certainly all the major ones. I just can't get into it, and when I try, it just feels like it's stuck in the past as an ecosystem, and I revert to Scheme or another language. The notebooks in F# and Elixir are gamechangers, in my opinion, for learning, going through books, and even production uses. The various Common Lisp books are awesome, but I use F#, Elixir, and Racket when working through the bits I do write code for.
- vindarel 3y ago
  Today other editors have good to very good support, such as Vim or Atom/Pulsar: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... the VSCode plugin is here and evolving, we can use Jupyter notebooks, and even a very cool editor written in CL, working out of the box for CL and other languages with its built-in LSP client, Lem.
- eadmund 3y ago
  > It's mainly that the core editor is Emacs What’s the problem with that? Emacs is, on balance, the best editor and ecosystem. Nothing else comes close, and time spent on anything else is ultimately wasted. > I don't think I'll ever have the time to actually understand things like CLOS and the metaobject protocol in Common Lisp. They are really worth considering. I have found that the longer I use them, the wiser the decisions they encode were. > The condition system seems pretty cool. It really is. The more you get used to it, the more intolerable it is that other languages don’t provide something similar out of the box. Common Lisp isn’t perfect, of course. It has some very real flaws! But at the end of the day, nothing else matches it, even though over the past three decades the baseline language has gotten closer. Garbage collection was a huge win on the past. Gradual typing, too. But the baseline language of today still doesn’t have macros. It still doesn’t have something approaching CLOS, let alone the MOP. Almost no languages have reasonable condition handling. In a ton of ways, Common Lisp is an improvement on its successors.
  - bmitc 3y ago
    > What’s the problem with that? Emacs is, on balance, the best editor and ecosystem. Nothing else comes close, and time spent on anything else is ultimately wasted. That is a pretty strong statement. Every time I try Emacs I revert to VS Code. Is it as immediately programmable? No. But it doesn't have to be because the extensions are plenty and quite good and work without mucking about with .emacs. One can go quite deep with it when developing an extension, though. VS Code has the remote server extensions as well, which are seamless. I use VS Code on three or four different computers (as in running it as a GUI as a desktop app) every day all the while developing locally, in a Docker container, in a Linux distribution through WSL, or SSHed into several Linux machines. My settings and extensions automatically sync, the extensions just work on any machine including while remoting, and its all seamless from use case to use case. No other editor has this experience. Plus, it supports rich graphics like Markdown preview, HTML preview, notebooks like Polyglot Notebooks that can share data between cells in different languages and display images and animations, and more. Emacs does not have that support to the same degree. > Almost no languages have reasonable condition handling. That's true. But Erlang and Elixir are major contenders. Erlang actually probably got there first.
BaculumMeumEst 3y ago
It doesn't give you good tools for networking, for writing concurrent or asynchronous code, for graphics, it doesn't give you a good package manager or means of distributing code, its data structures are unwieldy, it takes work to make it performant, etc. The obstacles add up, and the time you spend on these issues by dealing with hopefully supported community libraries or rolling your own is time spent not dealing with the real problem you're trying to solve. Racket and Clojure are better suited for pragmatic use in my opinion/experience.
- jll29 3y ago
  Perhaps you can get some of the advantages that you cite as missing by using an embedded LISP or Scheme implemented in Rust, so you can piggy-back on Rust's nice ecosystem and still have a dynamic "LISP sub-system". For instance: https://github.com/isamert/scheme.rs https://github.com/isamert/scheme.rs (a Scheme in 3853 lines of Rust)
  - kitd 3y ago
    That's really what Clojure is, except based on the JVM, with access to the Java stdlib.
- vindarel 3y ago
  > obstacles add up I actually agree. It wasn't smooth for me to ship my first CL app. It's all better now (more tools, more documentation, more blog posts from several people, more SO questions and answers!). > performant SBCL is in the same ballpack of C, Rust or Java in many benchmarks. In this article series, the author writes the same program in CL, Rust and Java. In fact, he copy-pastes a PG snippet from 30 years ago. This snippet beats Rust and Java in LOC and speed. But, yeah, he wasn't writing super efficient Rust code, so after many discussions, pull requests and sweating, the Rust code became the most performant. https://renato.athaydes.com/posts/revisiting-prechelt-paper-comparing-languages.html https://renato.athaydes.com/posts/revisiting-prechelt-paper-... It didn't take work to make the CL code performant, more so for the Rust one ;) a benchmark after sb-simd vectorization: https://preview.redd.it/vn5juu36v2681.png?width=715&format=png&auto=webp&s=266dde2daf33c6767531fa635d436ac9657d63c8 https://preview.redd.it/vn5juu36v2681.png?width=715&format=p... (https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_amazing_sbcl_benchmark_speed_with_sbsimd/ https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_a...) > good tools for networking, for writing concurrent or asynchronous code, for graphics, I refer the reader to https://github.com/CodyReichert/awesome-cl https://github.com/CodyReichert/awesome-cl but yes, CL won't have the best libraries in some scenarii (GUI? Tk libs are good, we have Gtk4, a Qt5 library used in production© by a big player but difficult to install etc) > it doesn't give you a good package manager or means of distributing code Quicklisp is neat, with limitations, that can be addressed with Qlot, ql-https, or CLPM or the newest ocicl.

It's mainly that the core editor is Emacs or proprietary ones that have indeterminate futures, there are different implementations that are incompatible for things not defined in the standard, such as for GUIs, not a well defined and vibrant ecosystem or community, the package system is strange, and other things of this nature. As a language, I think it has a bit of cruft from being a mismash of everyone's favorite features from all the Lisps around the time that the standard was created. I find that it is hard to read, and this is coming from someone who likes Schemes and doesn't care about parentheses. Furthermore, you will struggle finding a job. Although admittedly, the jobs you do find may be cool. But they may also be giant balls of mud, which is my main impression and true from what I have read. I think for personal or dedicated use cases within a larger system it is probably awesome. For example, I believe the CLR (.NET) garbage collector was generated via Common Lisp code. I personally use other languages for my personal projects, namely F# and Elixir, and when I want to reach for a Lisp/Scheme, I choose Racket. I find Scheme a more focused language. I don't think I'll ever have the time to actually understand things like CLOS and the metaobject protocol in Common Lisp. The condition system seems pretty cool. I have practically every Lisp book there is, and certainly all the major ones. I just can't get into it, and when I try, it just feels like it's stuck in the past as an ecosystem, and I revert to Scheme or another language. The notebooks in F# and Elixir are gamechangers, in my opinion, for learning, going through books, and even production uses. The various Common Lisp books are awesome, but I use F#, Elixir, and Racket when working through the bits I do write code for.

vindarel 3y ago
Today other editors have good to very good support, such as Vim or Atom/Pulsar: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... the VSCode plugin is here and evolving, we can use Jupyter notebooks, and even a very cool editor written in CL, working out of the box for CL and other languages with its built-in LSP client, Lem.
eadmund 3y ago
> It's mainly that the core editor is Emacs What’s the problem with that? Emacs is, on balance, the best editor and ecosystem. Nothing else comes close, and time spent on anything else is ultimately wasted. > I don't think I'll ever have the time to actually understand things like CLOS and the metaobject protocol in Common Lisp. They are really worth considering. I have found that the longer I use them, the wiser the decisions they encode were. > The condition system seems pretty cool. It really is. The more you get used to it, the more intolerable it is that other languages don’t provide something similar out of the box. Common Lisp isn’t perfect, of course. It has some very real flaws! But at the end of the day, nothing else matches it, even though over the past three decades the baseline language has gotten closer. Garbage collection was a huge win on the past. Gradual typing, too. But the baseline language of today still doesn’t have macros. It still doesn’t have something approaching CLOS, let alone the MOP. Almost no languages have reasonable condition handling. In a ton of ways, Common Lisp is an improvement on its successors.
- bmitc 3y ago
  > What’s the problem with that? Emacs is, on balance, the best editor and ecosystem. Nothing else comes close, and time spent on anything else is ultimately wasted. That is a pretty strong statement. Every time I try Emacs I revert to VS Code. Is it as immediately programmable? No. But it doesn't have to be because the extensions are plenty and quite good and work without mucking about with .emacs. One can go quite deep with it when developing an extension, though. VS Code has the remote server extensions as well, which are seamless. I use VS Code on three or four different computers (as in running it as a GUI as a desktop app) every day all the while developing locally, in a Docker container, in a Linux distribution through WSL, or SSHed into several Linux machines. My settings and extensions automatically sync, the extensions just work on any machine including while remoting, and its all seamless from use case to use case. No other editor has this experience. Plus, it supports rich graphics like Markdown preview, HTML preview, notebooks like Polyglot Notebooks that can share data between cells in different languages and display images and animations, and more. Emacs does not have that support to the same degree. > Almost no languages have reasonable condition handling. That's true. But Erlang and Elixir are major contenders. Erlang actually probably got there first.

BaculumMeumEst 3y ago

It doesn't give you good tools for networking, for writing concurrent or asynchronous code, for graphics, it doesn't give you a good package manager or means of distributing code, its data structures are unwieldy, it takes work to make it performant, etc. The obstacles add up, and the time you spend on these issues by dealing with hopefully supported community libraries or rolling your own is time spent not dealing with the real problem you're trying to solve. Racket and Clojure are better suited for pragmatic use in my opinion/experience.

jll29 3y ago
Perhaps you can get some of the advantages that you cite as missing by using an embedded LISP or Scheme implemented in Rust, so you can piggy-back on Rust's nice ecosystem and still have a dynamic "LISP sub-system". For instance: https://github.com/isamert/scheme.rs https://github.com/isamert/scheme.rs (a Scheme in 3853 lines of Rust)
- kitd 3y ago
  That's really what Clojure is, except based on the JVM, with access to the Java stdlib.
vindarel 3y ago
> obstacles add up I actually agree. It wasn't smooth for me to ship my first CL app. It's all better now (more tools, more documentation, more blog posts from several people, more SO questions and answers!). > performant SBCL is in the same ballpack of C, Rust or Java in many benchmarks. In this article series, the author writes the same program in CL, Rust and Java. In fact, he copy-pastes a PG snippet from 30 years ago. This snippet beats Rust and Java in LOC and speed. But, yeah, he wasn't writing super efficient Rust code, so after many discussions, pull requests and sweating, the Rust code became the most performant. https://renato.athaydes.com/posts/revisiting-prechelt-paper-comparing-languages.html https://renato.athaydes.com/posts/revisiting-prechelt-paper-... It didn't take work to make the CL code performant, more so for the Rust one ;) a benchmark after sb-simd vectorization: https://preview.redd.it/vn5juu36v2681.png?width=715&format=png&auto=webp&s=266dde2daf33c6767531fa635d436ac9657d63c8 https://preview.redd.it/vn5juu36v2681.png?width=715&format=p... (https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_amazing_sbcl_benchmark_speed_with_sbsimd/ https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_a...) > good tools for networking, for writing concurrent or asynchronous code, for graphics, I refer the reader to https://github.com/CodyReichert/awesome-cl https://github.com/CodyReichert/awesome-cl but yes, CL won't have the best libraries in some scenarii (GUI? Tk libs are good, we have Gtk4, a Qt5 library used in production© by a big player but difficult to install etc) > it doesn't give you a good package manager or means of distributing code Quicklisp is neat, with limitations, that can be addressed with Qlot, ql-https, or CLPM or the newest ocicl.