5 ms·

Haha, no. Modern PLs have reached parity with Lisps but comparing C and Lisp is apples and oranges. C was fast no doubt but much lower level than LISP and serv

Haha, no. Modern PLs have reached parity with Lisps but comparing C and Lisp is apples and oranges. C was fast no doubt but much lower level than LISP and served a different purpose. And then you proceed to link someone’s comment as a reference? Nobody is trying to convince you to use Lisp, it’s just free books you could learn from if interested. The hostility is hard to understand.

bmitc 3y ago
Their point was that the "superpowers" and mythology of Lisp come from a time (the 80s) in which C was the primary alternative, popular language. Standard ML came later and the further MLs in OCaml and F# came much, much later. Erlang was proprietary. Prolog was around but misunderstood and remains so. Smalltalk was there and super powerful (maybe moreso?), but as far as I understand, kept to certain machines. But now we have Elixir, Erlang, F#, OCaml, Scala, Racket, Chez Scheme, Gerbil Scheme, Chicken Scheme, Ruby, Python, Clojure, Pharo, etc. all competing with the standardized Lisp in Common Lisp. I love Lisp, or rather Scheme and its ilk, but the point is that its mythology comes from the 80s and early 90s in which it did sort of set the standard for modern languages. It's really a fantastic family of languages, but there doesn't seem to be one that really stands out as pragmatic, industrial alternatives to the other languages it has heavily inspired. It seems Clojure and Racket come close, and Common Lisp is just too "hardcore" for pragmatic use, in my opinion.
- fuzztester 3y ago
  >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.
- vindarel 3y ago
  > but there doesn't seem to be one that really stands out as pragmatic, industrial disagree ;) This industrial language is Common Lisp. Some industrial uses: - http://www.lispworks.com/success-stories/index.html http://www.lispworks.com/success-stories/index.html - https://github.com/azzamsa/awesome-lisp-companies/ https://github.com/azzamsa/awesome-lisp-companies/ - https://lisp-lang.org/success/ https://lisp-lang.org/success/ Example companies: Intel's programmable chips, the ACL2 theorem prover (https://royalsocietypublishing.org/doi/10.1098/rsta.2015.0399 https://royalsocietypublishing.org/doi/10.1098/rsta.2015.039...), urban transportation planning systems (SISCOG), Quantum Computing (HRL Labs, Rigetti…), big data financial analysis (Ravenpack, they might be hiring), Google, Boeing, the NASA, etc. ps: Python competing? strong disagree^^ (edit) on using a CL library that adds Haskell-like type checking on top of CL to develop an industrial quantum compiler: https://coalton-lang.github.io/20220906-quantum-compiler/ https://coalton-lang.github.io/20220906-quantum-compiler/
  - bmitc 3y ago
    Those industrial use lists are way out of date though. Many of the companies don't exist anymore, last I checked. And the presence of companies using Common Lisp doesn't really negate my comment. It certainly has its niches, which is probably what it is best at. But I highly doubt one could convince, at the outset of the project, a company that chose Elixir to instead use Common Lisp, for example. There are lots of companies actively using Elixir. > ps: Python competing? strong disagree^^ I pretty strongly dislike Python, but we have to admit that any language today is competing against it in terms of mindshare, despite several languages being much better designed.
- lispm 3y ago
  An example: I bought a slick application for macOS & Windows: OpusModus ( https://opusmodus.com https://opusmodus.com ). It's a Lisp IDE tailored for algorithmic Music composition. The Mac version is just a normal desktop app in the Applications folder. It automatically runs on Intel and Apple Silicon, natively. Upon download it is expanded to a Mac application. It has a native user interface. For sound generation it can use a Lisp library which compiles sound generators to C, which then get compiled by Xcode and loaded into Lisp all at runtime. Typically it talks via Midi to other applications (Logic, Mainstage, Ableton, ...). It creates nice looking scores... There is also a Windows application, with the same features, native code & native UI, ... I find that pretty cool for a language & application which is super niche. OpusModus 3 is written in LispWorks (first released end 80s on Unix machines), a commercial Common Lisp, which can be used for such Desktop applications.
  - bmitc 3y ago
    That is indeed an impressive application. Thank you for sharing. (I'm having trouble with the website on a tablet though.) Is there any talk where the author describes it?
    - lispm 3y ago
      I would propose to watch the linked Youtube video: https://www.youtube.com/watch?v=BMoHE96rh7w https://www.youtube.com/watch?v=BMoHE96rh7w It's actually several people working on it. Yes, one can develop Lisp software with more than one person. ;-)
- pjmlp 3y ago
  During the 80's C was hardly the primary alternative to anything outside UNIX.

bmitc 3y ago

Their point was that the "superpowers" and mythology of Lisp come from a time (the 80s) in which C was the primary alternative, popular language. Standard ML came later and the further MLs in OCaml and F# came much, much later. Erlang was proprietary. Prolog was around but misunderstood and remains so. Smalltalk was there and super powerful (maybe moreso?), but as far as I understand, kept to certain machines. But now we have Elixir, Erlang, F#, OCaml, Scala, Racket, Chez Scheme, Gerbil Scheme, Chicken Scheme, Ruby, Python, Clojure, Pharo, etc. all competing with the standardized Lisp in Common Lisp. I love Lisp, or rather Scheme and its ilk, but the point is that its mythology comes from the 80s and early 90s in which it did sort of set the standard for modern languages. It's really a fantastic family of languages, but there doesn't seem to be one that really stands out as pragmatic, industrial alternatives to the other languages it has heavily inspired. It seems Clojure and Racket come close, and Common Lisp is just too "hardcore" for pragmatic use, in my opinion.

fuzztester 3y ago
>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.
vindarel 3y ago
> but there doesn't seem to be one that really stands out as pragmatic, industrial disagree ;) This industrial language is Common Lisp. Some industrial uses: - http://www.lispworks.com/success-stories/index.html http://www.lispworks.com/success-stories/index.html - https://github.com/azzamsa/awesome-lisp-companies/ https://github.com/azzamsa/awesome-lisp-companies/ - https://lisp-lang.org/success/ https://lisp-lang.org/success/ Example companies: Intel's programmable chips, the ACL2 theorem prover (https://royalsocietypublishing.org/doi/10.1098/rsta.2015.0399 https://royalsocietypublishing.org/doi/10.1098/rsta.2015.039...), urban transportation planning systems (SISCOG), Quantum Computing (HRL Labs, Rigetti…), big data financial analysis (Ravenpack, they might be hiring), Google, Boeing, the NASA, etc. ps: Python competing? strong disagree^^ (edit) on using a CL library that adds Haskell-like type checking on top of CL to develop an industrial quantum compiler: https://coalton-lang.github.io/20220906-quantum-compiler/ https://coalton-lang.github.io/20220906-quantum-compiler/
- bmitc 3y ago
  Those industrial use lists are way out of date though. Many of the companies don't exist anymore, last I checked. And the presence of companies using Common Lisp doesn't really negate my comment. It certainly has its niches, which is probably what it is best at. But I highly doubt one could convince, at the outset of the project, a company that chose Elixir to instead use Common Lisp, for example. There are lots of companies actively using Elixir. > ps: Python competing? strong disagree^^ I pretty strongly dislike Python, but we have to admit that any language today is competing against it in terms of mindshare, despite several languages being much better designed.
lispm 3y ago
An example: I bought a slick application for macOS & Windows: OpusModus ( https://opusmodus.com https://opusmodus.com ). It's a Lisp IDE tailored for algorithmic Music composition. The Mac version is just a normal desktop app in the Applications folder. It automatically runs on Intel and Apple Silicon, natively. Upon download it is expanded to a Mac application. It has a native user interface. For sound generation it can use a Lisp library which compiles sound generators to C, which then get compiled by Xcode and loaded into Lisp all at runtime. Typically it talks via Midi to other applications (Logic, Mainstage, Ableton, ...). It creates nice looking scores... There is also a Windows application, with the same features, native code & native UI, ... I find that pretty cool for a language & application which is super niche. OpusModus 3 is written in LispWorks (first released end 80s on Unix machines), a commercial Common Lisp, which can be used for such Desktop applications.
- bmitc 3y ago
  That is indeed an impressive application. Thank you for sharing. (I'm having trouble with the website on a tablet though.) Is there any talk where the author describes it?
  - lispm 3y ago
    I would propose to watch the linked Youtube video: https://www.youtube.com/watch?v=BMoHE96rh7w https://www.youtube.com/watch?v=BMoHE96rh7w It's actually several people working on it. Yes, one can develop Lisp software with more than one person. ;-)
pjmlp 3y ago
During the 80's C was hardly the primary alternative to anything outside UNIX.