5 ms·

Clojure is really your better bet. It is highly practical with a good community and excellent Java interop. You never have to worry about finding a good library

by cultus 8y ago

Clojure is really your better bet. It is highly practical with a good community and excellent Java interop. You never have to worry about finding a good library. The syntax is also a bit more easily parsable than CL. If you don't touch the Java interop stuff, it's just as elegant as CL.

typon 8y ago
I've spent a few months learning Clojure - never gave CL a try. Here are a few thoughts on Clojure: 1. Excellent syntax and library support. It is my first Lisp, but I can't how I programmed without macros and persistent data structures. 2. I hate the stack traces. I've used both Clojure and Clojurescript (mainly cljs), and the stack traces for errors are nearly indecipherable. To be fair I am using React (not Reagent), but I don't find it too much better with other libraries. 3. I hate the build system. It is fractured and there are too many mediocre options. shadow-cljs is the best one I've used, and it works okay not great. I also hate that I can't distribute standalone binaries. I have used pkg, which distributes Node project as binaries, but the binaries are huge (something like 85MB+) 4. The core functional language is excellent, but protocols, types etc. seem much more ad-hoc and not well-designed. I'm used to object oriented (Python) and I find the lack of focus on an object-system a bit unsettling. I have no clue if Common Lisp fixes these issues or brings new ones.
- serpix 8y ago
  To date I have not come up with a situation needing protocols or objects in Clojure that could not be just done with functional programming. The real killer superpowers come from extend-type and extend-protocol. You can modify existing java/clojure libraries functionality like magic. The functional equivalent is with-binding if I remember correctly. Some Clojure libraries use protocols heavily and IMHO not just necessary.
- pjmlp 8y ago
  > The core functional language is excellent, but protocols, types etc. seem much more ad-hoc and not well-designed. I'm used to object oriented (Python) and I find the lack of focus on an object-system a bit unsettling. I guess CLOS was well designed. What Clojure offers is a subset of CLOS.
  - cultus 8y ago
    Clojure multimethods actually can do more than CL multiple dispatch, because they can dispatch by value rather than just type.
    - guicho271828 8y ago
      CLOS can dispatch by value with eql specifier...
    - fiddlerwoaroof 8y ago
      You can implement Clojure multimethods as an extension of CLOS: https://github.com/pcostanza/filtered-functions https://github.com/pcostanza/filtered-functions
- lispm 8y ago
  > 2. I hate the stack traces. I've used both Clojure and Clojurescript (mainly cljs), and the stack traces for errors are nearly indecipherable. To be fair I am using React (not Reagent), but I don't find it too much better with other libraries. Stack traces are already the wrong approach. Error handling is first. Stack traces may serve some purpose, but are secondary. Common Lisp was designed for interactive error handling. An example. Let's say we have a function FAK and it returns the wrong result "0" for 0. CL-USER 21 > (defun fak (n) (if (zerop n) "0" (* n (fak (1- n))))) FAK Now we call it with the argument 10: CL-USER 22 > (fak 10) Error: In * of (1 "0") arguments should be of type NUMBER. 1 (continue) Return a value to use. 2 Supply a new second argument. 3 (abort) Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. The first thing you see: no stack trace. We get a clear error message and three options what to do: CONTINUE, supply a new argument, ABORT. But we also get another REPL, but this time one level down and the original REPL is still there, one level up. This means we can do some computations in the error REPL: CL-USER 23 : 1 > (fak 0) "0" CL-USER 24 : 1 > (fak 1) Error: In * of (1 "0") arguments should be of type NUMBER. 1 (continue) Return a value to use. 2 Supply a new second argument. 3 (abort) return to debug level 1. 4 Return a value to use. 5 Supply a new second argument. 6 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. OOPS: we have another error. (fak 1) already does not work. Now we have more options to continue, while we are another error level deeper: 2. So we decide to go one error level up and explore the problem there further. :c 3 chooses the restart to go to debug level 1. CL-USER 25 : 2 > :c 3 Now we choose the CONTINUE restart from level 1. We just return 1 from the call, which was causing the error. The value 1 would be the correct result. Lisp now asks us for the value to use and we type 1: CL-USER 26 : 1 > :c 1 Supply a form to be evaluated and used: 1 3628800 So we explored the problem and got useful result without ever using a stack trace. Instead we used the tools: debug repls, clear error messages, restarts recovering from errors. Sure we can also get a stack trace - but the stacktrace is active in the context of the error - it's now a post-error stack trace - it's an in-error stack trace. Means we can, while we are in the error, see the stack trace and use it: change variables, restart start frames, return from stack frames, set break points to stack frames, ... Let's say we are in the error again. Let's get a quick backtrace: CL-USER 58 : 1 > :bq ERROR <- * <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- EVAL <- CAPI::CAPI-TOP-LEVEL-FUNCTION <- CAPI::INTERACTIVE-PANE-TOP-LOOP <- MP::PROCESS-SG-FUNCTION Now we can move in the backtrace down three times: CL-USER 59 : 1 > :n Call to * CL-USER 60 : 1 > :n Interpreted call to FAK CL-USER 61 : 1 > :n Interpreted call to FAK Let's see the variables in this stack frame: CL-USER 62 : 1 > :v Interpreted call to FAK: N : 2 Okay N is 2. So FAK from 2 should be 2. Let's try to return it. We call :ret 2, which will return the value 2 from the current stack frame. CL-USER 63 : 1 > :ret 2 3628800 This gave us the correct result. We used more tools: printing a stack trace overview, moving down the stack, looking at a stack frame's bindings and returning a value from a specific stack frame. There are lots of ways to work with a stack trace while we are in the error - the display of the stack trace is only a minor feature.
- socksy 8y ago
  I'm not sure it's fair to bring up a fractured build system when talking about ClojureScript, and comparing it to Common Lisp, which you would not be compiling to JavaScript and interop'ing with NodeJS etc. With (JVM) Clojure, leiningen has to be 90+% of the Clojure projects in the wild. And in that world, the equivalent to a native binary is an uberjar, which is rather easy and pretty much standardized. The stack traces could be improved though.
  - lispm 8y ago
    > Common Lisp, which you would not be compiling to JavaScript and interop'ing with NodeJS etc. https://jscl-project.github.io https://jscl-project.github.io https://common-lisp.net/project/parenscript/ https://common-lisp.net/project/parenscript/
    - socksy 8y ago
      That's great, are you using these? How is the interop? How does that compare with ClojureScript and shadow-cljs? How can you make a single binary? Maybe I worded wrongly the first time. I definitely didn't mean to imply that Common Lisp can't do something. That would be as foolish as saying Emacs can't do something ;) I was just pointing out that we aren't comparing like-with-like once you bring in a totally different ecosystem such as JavaScript's (which is historically neither Common Lisp's nor Clojure's main focus).
      - lispm 8y ago
        > That's great, are you using these? Not often. In Common Lisp I don't have to use them.
geokon 8y ago
I'm not very deep into Clojure - but I find that you end up having to use Java libraries which feels kinda clumsy. Java is a stateful language and Clojure has it's own ideas about how state is managed - so I'm never quite sure how to mix the two (based on some very limited experience... so I might be off-base)
- mclehman 8y ago
  I'm also not very deep into Clojure, but I've had the opposite experience so far. I've used it for some real-world projects and the most Java I've ever needed to pull in was a BufferedReader that I wrapped and forgot about.
_emacsomancer_ 8y ago
Is it reasonable to do Clojure and not have to touch Java?
- cultus 8y ago
  It's very possible. I use Clojure on a daily basis, and I only rarely need Java interop to use pretty obscure libraries. It's not that bad, it's not any worse than using Java directly.
armitron 8y ago
No, Clojure is not as elegant (or flexible) as Common Lisp, not even close. Also, how can Clojure be highly practical when it ties you to the JVM? When it forces its worldview on state down your throat? When it prematurely optimizes with concepts like STM? Common Lisp is all about choices and flexibility. Do you want pattern matching? You can get it but it's not shoved down your throat. Same for STM. Same for immutable data structures. Same for Java interop. On the other hand, Clojure is lacking fundamental features of Common Lisp that are extremely powerful: conditions & restarts, programmable debugger, programmable reader, programmable compiler through compiler macros, dumping images & native code compilation not to mention advanced code analysis and optimization capabilities.
- cultus 8y ago
  >Also, how can Clojure be highly practical when it ties you to the JVM? The JVM allows you to use a ton of libraries, on a very performant platform. CL libraries just aren't anywhere near as feature-complete as in more popular languages, and this matters when you actually need to be productive. I don't have time to reinvent the wheel constantly. This practicality is what motivated Clojure in the first place, and why it is far and away the most popular lisp.
  - armitron 8y ago
    I guess your definition of practical differs from mine. For me practicality is tied directly to usability in solving a widely disparate set of problems. This means that flexibility is key. The language I use should not only be able to bend and adapt to the problem at hand but also _not constrain my thinking_. The latter is also known as 'metalinguistic abstraction' and is strongly expressed in SICP as the philosophy of Lisp. Clojure mostly bypasses that since it has a very opinionated but also very constrained view on the problem-solving design space. As an example of metalinguistic abstraction, some of the tasks I've successfully deployed Common Lisp at include creating a high-performance network stack that runs on ARMv8 and is based on JIT compilation and an entire assortment of solutions that sit on opposite ends of the highlevel-lowlevel spectrum. Concepts such as tight control over memory, stack allocation and one-to-one mapping with generated instructions were critical. Common Lisp allowed me not only to successfully investigate the domain but also to use the resulting code in production. For these tasks, Clojure would have been a total miss both due to implementation decisions (JVM) and its constraining nature -- in this case, immutability, memory and compilation model -- not allowing me to come up with a 'language' that will let me think the right thoughts.

by cultus 8y ago

typon 8y ago

I've spent a few months learning Clojure - never gave CL a try. Here are a few thoughts on Clojure: 1. Excellent syntax and library support. It is my first Lisp, but I can't how I programmed without macros and persistent data structures. 2. I hate the stack traces. I've used both Clojure and Clojurescript (mainly cljs), and the stack traces for errors are nearly indecipherable. To be fair I am using React (not Reagent), but I don't find it too much better with other libraries. 3. I hate the build system. It is fractured and there are too many mediocre options. shadow-cljs is the best one I've used, and it works okay not great. I also hate that I can't distribute standalone binaries. I have used pkg, which distributes Node project as binaries, but the binaries are huge (something like 85MB+) 4. The core functional language is excellent, but protocols, types etc. seem much more ad-hoc and not well-designed. I'm used to object oriented (Python) and I find the lack of focus on an object-system a bit unsettling. I have no clue if Common Lisp fixes these issues or brings new ones.

serpix 8y ago
To date I have not come up with a situation needing protocols or objects in Clojure that could not be just done with functional programming. The real killer superpowers come from extend-type and extend-protocol. You can modify existing java/clojure libraries functionality like magic. The functional equivalent is with-binding if I remember correctly. Some Clojure libraries use protocols heavily and IMHO not just necessary.
pjmlp 8y ago
> The core functional language is excellent, but protocols, types etc. seem much more ad-hoc and not well-designed. I'm used to object oriented (Python) and I find the lack of focus on an object-system a bit unsettling. I guess CLOS was well designed. What Clojure offers is a subset of CLOS.
- cultus 8y ago
  Clojure multimethods actually can do more than CL multiple dispatch, because they can dispatch by value rather than just type.
  - guicho271828 8y ago
    CLOS can dispatch by value with eql specifier...
  - fiddlerwoaroof 8y ago
    You can implement Clojure multimethods as an extension of CLOS: https://github.com/pcostanza/filtered-functions https://github.com/pcostanza/filtered-functions
lispm 8y ago
> 2. I hate the stack traces. I've used both Clojure and Clojurescript (mainly cljs), and the stack traces for errors are nearly indecipherable. To be fair I am using React (not Reagent), but I don't find it too much better with other libraries. Stack traces are already the wrong approach. Error handling is first. Stack traces may serve some purpose, but are secondary. Common Lisp was designed for interactive error handling. An example. Let's say we have a function FAK and it returns the wrong result "0" for 0. CL-USER 21 > (defun fak (n) (if (zerop n) "0" (* n (fak (1- n))))) FAK Now we call it with the argument 10: CL-USER 22 > (fak 10) Error: In * of (1 "0") arguments should be of type NUMBER. 1 (continue) Return a value to use. 2 Supply a new second argument. 3 (abort) Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. The first thing you see: no stack trace. We get a clear error message and three options what to do: CONTINUE, supply a new argument, ABORT. But we also get another REPL, but this time one level down and the original REPL is still there, one level up. This means we can do some computations in the error REPL: CL-USER 23 : 1 > (fak 0) "0" CL-USER 24 : 1 > (fak 1) Error: In * of (1 "0") arguments should be of type NUMBER. 1 (continue) Return a value to use. 2 Supply a new second argument. 3 (abort) return to debug level 1. 4 Return a value to use. 5 Supply a new second argument. 6 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. OOPS: we have another error. (fak 1) already does not work. Now we have more options to continue, while we are another error level deeper: 2. So we decide to go one error level up and explore the problem there further. :c 3 chooses the restart to go to debug level 1. CL-USER 25 : 2 > :c 3 Now we choose the CONTINUE restart from level 1. We just return 1 from the call, which was causing the error. The value 1 would be the correct result. Lisp now asks us for the value to use and we type 1: CL-USER 26 : 1 > :c 1 Supply a form to be evaluated and used: 1 3628800 So we explored the problem and got useful result without ever using a stack trace. Instead we used the tools: debug repls, clear error messages, restarts recovering from errors. Sure we can also get a stack trace - but the stacktrace is active in the context of the error - it's now a post-error stack trace - it's an in-error stack trace. Means we can, while we are in the error, see the stack trace and use it: change variables, restart start frames, return from stack frames, set break points to stack frames, ... Let's say we are in the error again. Let's get a quick backtrace: CL-USER 58 : 1 > :bq ERROR <- * <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- FAK <- EVAL <- CAPI::CAPI-TOP-LEVEL-FUNCTION <- CAPI::INTERACTIVE-PANE-TOP-LOOP <- MP::PROCESS-SG-FUNCTION Now we can move in the backtrace down three times: CL-USER 59 : 1 > :n Call to * CL-USER 60 : 1 > :n Interpreted call to FAK CL-USER 61 : 1 > :n Interpreted call to FAK Let's see the variables in this stack frame: CL-USER 62 : 1 > :v Interpreted call to FAK: N : 2 Okay N is 2. So FAK from 2 should be 2. Let's try to return it. We call :ret 2, which will return the value 2 from the current stack frame. CL-USER 63 : 1 > :ret 2 3628800 This gave us the correct result. We used more tools: printing a stack trace overview, moving down the stack, looking at a stack frame's bindings and returning a value from a specific stack frame. There are lots of ways to work with a stack trace while we are in the error - the display of the stack trace is only a minor feature.
socksy 8y ago
I'm not sure it's fair to bring up a fractured build system when talking about ClojureScript, and comparing it to Common Lisp, which you would not be compiling to JavaScript and interop'ing with NodeJS etc. With (JVM) Clojure, leiningen has to be 90+% of the Clojure projects in the wild. And in that world, the equivalent to a native binary is an uberjar, which is rather easy and pretty much standardized. The stack traces could be improved though.
- lispm 8y ago
  > Common Lisp, which you would not be compiling to JavaScript and interop'ing with NodeJS etc. https://jscl-project.github.io https://jscl-project.github.io https://common-lisp.net/project/parenscript/ https://common-lisp.net/project/parenscript/
  - socksy 8y ago
    That's great, are you using these? How is the interop? How does that compare with ClojureScript and shadow-cljs? How can you make a single binary? Maybe I worded wrongly the first time. I definitely didn't mean to imply that Common Lisp can't do something. That would be as foolish as saying Emacs can't do something ;) I was just pointing out that we aren't comparing like-with-like once you bring in a totally different ecosystem such as JavaScript's (which is historically neither Common Lisp's nor Clojure's main focus).
    - lispm 8y ago
      > That's great, are you using these? Not often. In Common Lisp I don't have to use them.

geokon 8y ago

I'm not very deep into Clojure - but I find that you end up having to use Java libraries which feels kinda clumsy. Java is a stateful language and Clojure has it's own ideas about how state is managed - so I'm never quite sure how to mix the two (based on some very limited experience... so I might be off-base)

mclehman 8y ago
I'm also not very deep into Clojure, but I've had the opposite experience so far. I've used it for some real-world projects and the most Java I've ever needed to pull in was a BufferedReader that I wrapped and forgot about.

_emacsomancer_ 8y ago

Is it reasonable to do Clojure and not have to touch Java?

cultus 8y ago
It's very possible. I use Clojure on a daily basis, and I only rarely need Java interop to use pretty obscure libraries. It's not that bad, it's not any worse than using Java directly.

armitron 8y ago

No, Clojure is not as elegant (or flexible) as Common Lisp, not even close. Also, how can Clojure be highly practical when it ties you to the JVM? When it forces its worldview on state down your throat? When it prematurely optimizes with concepts like STM? Common Lisp is all about choices and flexibility. Do you want pattern matching? You can get it but it's not shoved down your throat. Same for STM. Same for immutable data structures. Same for Java interop. On the other hand, Clojure is lacking fundamental features of Common Lisp that are extremely powerful: conditions & restarts, programmable debugger, programmable reader, programmable compiler through compiler macros, dumping images & native code compilation not to mention advanced code analysis and optimization capabilities.

cultus 8y ago
>Also, how can Clojure be highly practical when it ties you to the JVM? The JVM allows you to use a ton of libraries, on a very performant platform. CL libraries just aren't anywhere near as feature-complete as in more popular languages, and this matters when you actually need to be productive. I don't have time to reinvent the wheel constantly. This practicality is what motivated Clojure in the first place, and why it is far and away the most popular lisp.
- armitron 8y ago
  I guess your definition of practical differs from mine. For me practicality is tied directly to usability in solving a widely disparate set of problems. This means that flexibility is key. The language I use should not only be able to bend and adapt to the problem at hand but also _not constrain my thinking_. The latter is also known as 'metalinguistic abstraction' and is strongly expressed in SICP as the philosophy of Lisp. Clojure mostly bypasses that since it has a very opinionated but also very constrained view on the problem-solving design space. As an example of metalinguistic abstraction, some of the tasks I've successfully deployed Common Lisp at include creating a high-performance network stack that runs on ARMv8 and is based on JIT compilation and an entire assortment of solutions that sit on opposite ends of the highlevel-lowlevel spectrum. Concepts such as tight control over memory, stack allocation and one-to-one mapping with generated instructions were critical. Common Lisp allowed me not only to successfully investigate the domain but also to use the resulting code in production. For these tasks, Clojure would have been a total miss both due to implementation decisions (JVM) and its constraining nature -- in this case, immutability, memory and compilation model -- not allowing me to come up with a 'language' that will let me think the right thoughts.