4 ms·

Why not just use Clojure?

by qPM9l3XJrF 5y ago

nerdponx 5y ago
This is like asking "why not use Haskell?" in a Kotlin thread.
- qPM9l3XJrF 5y ago
  I don't follow. For context, I've been thinking about learning Clojure. I'm pretty new to the Lisp world--I went through most of SICP in Scheme years ago, but that's about it. In 2012 Clojure was HN's second favorite programming language: https://i.imgur.com/toGKy21.jpg https://i.imgur.com/toGKy21.jpg What's the best argument for me learning a Lisp besides Clojure? Serious question, I'm not particularly attached to Clojure, and I want to know what I will miss out on by going with it instead of some other Lisp.
  - cbrozefsky 5y ago
    Learn it, it's great, productive, wonderful ecosystem and community, and it will get you a Lisp variant that runs in a modern deployment context and has access to maybe the biggest ecosystem of libraries out there. You'll miss out on some of the details of cons cells, symbols and macros and such, but you'll get the meat of learning to work with a REPL, macros and all that.
  - nerdponx 5y ago
    Fair enough, I thought it was snark so I responded with snark. I think you should try both. Lisp as a language gives you a lot more freedom than Clojure, but Clojure has a more consistent and elegant language design. Clojure focuses on mostly-pure functional programming with immutable data structures, while Lisp lets you do pretty much anything anywhere, including hacking deep into the runtime itself (Clojure lets you do this to some extent too, but not as much as Lisp). Some videos that are worth viewing, which together I think provide a good sense of how the languages differ: - "Common Lisp for the Curious Clojurian" by Alan Diepert. A very lucid side-by-side comparison of Clojure and Common Lisp; assumes some but doesn't really require much knowledge of Clojure. https://www.youtube.com/watch?v=44Q9ew9JH_U https://www.youtube.com/watch?v=44Q9ew9JH_U - "Maybe Not" by Rich Hickey. An unusual but thoughtful take on "types" in programming, which I think cuts to the heart of what Clojure is all about. https://www.youtube.com/watch?v=YR5WdGrpoug https://www.youtube.com/watch?v=YR5WdGrpoug - "Immutable Conversations - Common Lisp" interview with Alejandro Serrano and Michał "phoe" Herda. Demonstrates the deep programmability and flexibility of the Common Lisp runtime, including its unique "condition system". https://www.youtube.com/watch?v=pkqQq2Hwt5o https://www.youtube.com/watch?v=pkqQq2Hwt5o
    - qPM9l3XJrF 5y ago
      Thanks!
Jach 5y ago
With what editor? (Rhetorical question, emacs and vim are dominant there too, providing another data point for "it's not the editor" that's somehow hindering Common Lisp's resurgence.)
- LandR 5y ago
  Clojure with VSCode and Calva is the best development experience I've ever used in any language.
- playing_colours 5y ago
  I have a good experience with Cursive IDE, built upon Intellij IDEA.
blacktriangle 5y ago
I'll bite. Tooling. The CIDER devs are doing a great job, but Clojure gets to suffer by being tightly coupled to the JVM. Meanwhile CL thought deeply about having a truly dynamic developer experience, for example look at the CL condition system. Multiparadigm. Sometimes I want an object, sometimes I want goto, sometimes I want to mutate a thing. CL is probably the least opinionated language every made, Clojure is highly opinionated. For a long-term investment, I want to have options. There's a spec. CL is done. I have faith my code will continue to run as-is well into the future. Hickey very much values long-term backward compatibility and maintenance today, but who knows what he'll value in the future? For that matter what does Clojure look like if he gets hit by a bus? I don't want to have to worry about things like that. CL has more parens. People love to complain about CL let's excessive parens, but I find them much easier to read, but more importantly they are much easier to work with when using structural editing tools, and easier to work with in macros. I find Clojure's extra syntax for literals to be a net negative. No JVM. The JVM is a mixed bag, if you need it for operational reasons then its a huge win, but if you're not constrained by somebody else organizational policies, then I think the JVM is a net loss. Instead of dealing with the JVM, CL gives you a variety of tools to tune performance to make your programs scream. Reader macros. Clojure rejects them as a giant footgun, CL gives them to you since CL is all about maximal power and flexibility for an uncertain future.
- qPM9l3XJrF 5y ago
  Thanks! I'm curious why you think the JVM is a net loss if you don't need it, if you want to elaborate on that.
  - lispm 5y ago
    For example some Lisps allow us to save the state of the heap to disk easily, incl. the runtime, to make an executable. This is then no special feature, saving is done in a second and starting the executable is also extremely fast. There is no extra tooling needed. That way one does not need to restore the state by loading a bunch of files. The default JVM does not support that. Code is by default compiled to native code -> no JIT needed. The JVM also does not support optimization of tail function calls into jumps. Thus the language either has to implement it in a slower way, provide limited hacks around it or omit that feature. Various Lisps provide full TCO as an optimization feature in the compiler. The JVM is also not optimized to represent Lisp data. For example the numerics of Common Lisp are relatively powerful and thoughtful designed with bignums/fixnums, ratios, complex numbers, etc.. The JVM has its own idea of numeric types and its operations. Common Lisp has CLOS as a very dynamic object system with an optional meta-object system. That maps also not directly to JVM classes/objects (no full multiple inheritance, no multi-methods, no method combinations, ...). One can implement that on top of the JVM, but it will always be slightly slower than a native Lisp implementation. Looking at compiled code / backtraces / ... on the JVM will always look slightly alien to a Lisp programmer - some Lisp implementations have simpler stack traces, tailored for Lisp. The positive side of the JVM is the better integration into the IT landscape, modern garbage collectors, a mature runtime with lots of users and the direct integration into Java/... software on the JVM. If we look at Common Lisp, there is a full implementation of Common Lisp on the JVM called ABCL. That's a great achieve, but native implementations like SBCL are much faster and thus more widely used amongst CL users. SBCL comes with the added bonus of an excellent native code compiler written in Lisp itself. I would recommend the SBCL compiler also for beginners, because it gives a lot of warnings and other information at compile-time.

Why not just use Clojure?

nerdponx 5y ago

This is like asking "why not use Haskell?" in a Kotlin thread.

qPM9l3XJrF 5y ago
I don't follow. For context, I've been thinking about learning Clojure. I'm pretty new to the Lisp world--I went through most of SICP in Scheme years ago, but that's about it. In 2012 Clojure was HN's second favorite programming language: https://i.imgur.com/toGKy21.jpg https://i.imgur.com/toGKy21.jpg What's the best argument for me learning a Lisp besides Clojure? Serious question, I'm not particularly attached to Clojure, and I want to know what I will miss out on by going with it instead of some other Lisp.
- cbrozefsky 5y ago
  Learn it, it's great, productive, wonderful ecosystem and community, and it will get you a Lisp variant that runs in a modern deployment context and has access to maybe the biggest ecosystem of libraries out there. You'll miss out on some of the details of cons cells, symbols and macros and such, but you'll get the meat of learning to work with a REPL, macros and all that.
- nerdponx 5y ago
  Fair enough, I thought it was snark so I responded with snark. I think you should try both. Lisp as a language gives you a lot more freedom than Clojure, but Clojure has a more consistent and elegant language design. Clojure focuses on mostly-pure functional programming with immutable data structures, while Lisp lets you do pretty much anything anywhere, including hacking deep into the runtime itself (Clojure lets you do this to some extent too, but not as much as Lisp). Some videos that are worth viewing, which together I think provide a good sense of how the languages differ: - "Common Lisp for the Curious Clojurian" by Alan Diepert. A very lucid side-by-side comparison of Clojure and Common Lisp; assumes some but doesn't really require much knowledge of Clojure. https://www.youtube.com/watch?v=44Q9ew9JH_U https://www.youtube.com/watch?v=44Q9ew9JH_U - "Maybe Not" by Rich Hickey. An unusual but thoughtful take on "types" in programming, which I think cuts to the heart of what Clojure is all about. https://www.youtube.com/watch?v=YR5WdGrpoug https://www.youtube.com/watch?v=YR5WdGrpoug - "Immutable Conversations - Common Lisp" interview with Alejandro Serrano and Michał "phoe" Herda. Demonstrates the deep programmability and flexibility of the Common Lisp runtime, including its unique "condition system". https://www.youtube.com/watch?v=pkqQq2Hwt5o https://www.youtube.com/watch?v=pkqQq2Hwt5o
  - qPM9l3XJrF 5y ago
    Thanks!

Jach 5y ago

With what editor? (Rhetorical question, emacs and vim are dominant there too, providing another data point for "it's not the editor" that's somehow hindering Common Lisp's resurgence.)

LandR 5y ago
Clojure with VSCode and Calva is the best development experience I've ever used in any language.
playing_colours 5y ago
I have a good experience with Cursive IDE, built upon Intellij IDEA.

blacktriangle 5y ago

I'll bite. Tooling. The CIDER devs are doing a great job, but Clojure gets to suffer by being tightly coupled to the JVM. Meanwhile CL thought deeply about having a truly dynamic developer experience, for example look at the CL condition system. Multiparadigm. Sometimes I want an object, sometimes I want goto, sometimes I want to mutate a thing. CL is probably the least opinionated language every made, Clojure is highly opinionated. For a long-term investment, I want to have options. There's a spec. CL is done. I have faith my code will continue to run as-is well into the future. Hickey very much values long-term backward compatibility and maintenance today, but who knows what he'll value in the future? For that matter what does Clojure look like if he gets hit by a bus? I don't want to have to worry about things like that. CL has more parens. People love to complain about CL let's excessive parens, but I find them much easier to read, but more importantly they are much easier to work with when using structural editing tools, and easier to work with in macros. I find Clojure's extra syntax for literals to be a net negative. No JVM. The JVM is a mixed bag, if you need it for operational reasons then its a huge win, but if you're not constrained by somebody else organizational policies, then I think the JVM is a net loss. Instead of dealing with the JVM, CL gives you a variety of tools to tune performance to make your programs scream. Reader macros. Clojure rejects them as a giant footgun, CL gives them to you since CL is all about maximal power and flexibility for an uncertain future.

qPM9l3XJrF 5y ago
Thanks! I'm curious why you think the JVM is a net loss if you don't need it, if you want to elaborate on that.
- lispm 5y ago
  For example some Lisps allow us to save the state of the heap to disk easily, incl. the runtime, to make an executable. This is then no special feature, saving is done in a second and starting the executable is also extremely fast. There is no extra tooling needed. That way one does not need to restore the state by loading a bunch of files. The default JVM does not support that. Code is by default compiled to native code -> no JIT needed. The JVM also does not support optimization of tail function calls into jumps. Thus the language either has to implement it in a slower way, provide limited hacks around it or omit that feature. Various Lisps provide full TCO as an optimization feature in the compiler. The JVM is also not optimized to represent Lisp data. For example the numerics of Common Lisp are relatively powerful and thoughtful designed with bignums/fixnums, ratios, complex numbers, etc.. The JVM has its own idea of numeric types and its operations. Common Lisp has CLOS as a very dynamic object system with an optional meta-object system. That maps also not directly to JVM classes/objects (no full multiple inheritance, no multi-methods, no method combinations, ...). One can implement that on top of the JVM, but it will always be slightly slower than a native Lisp implementation. Looking at compiled code / backtraces / ... on the JVM will always look slightly alien to a Lisp programmer - some Lisp implementations have simpler stack traces, tailored for Lisp. The positive side of the JVM is the better integration into the IT landscape, modern garbage collectors, a mature runtime with lots of users and the direct integration into Java/... software on the JVM. If we look at Common Lisp, there is a full implementation of Common Lisp on the JVM called ABCL. That's a great achieve, but native implementations like SBCL are much faster and thus more widely used amongst CL users. SBCL comes with the added bonus of an excellent native code compiler written in Lisp itself. I would recommend the SBCL compiler also for beginners, because it gives a lot of warnings and other information at compile-time.