3 ms·

This is really interesting, I write mostly Common Lisp as hobby projects (at varying levels of scale, I've submitted patches for sbcl and mcclim and I've writte

This is really interesting, I write mostly Common Lisp as hobby projects (at varying levels of scale, I've submitted patches for sbcl and mcclim and I've written a bunch of libraries) and at work I help maintain a data pipeline written in Clojure. I've generally found that I much prefer the "feeling" of writing Common Lisp and have come to think that immutability in the core + being hosted on the jvm forces some compromises on the interactive development front that make writing Clojure always feel like something of a chore.

jwr 8y ago
I had similar feelings in the very beginning, but I was quickly won over (I didn't see compromises in interactive development, though, unless you mean difficult debugging because of lazy sequences). Debugging in general was something I missed the most (after all, even in CL, I implemented return-from-frame in CMUCL to get better interactive debugging). And to this day I think CL has better interactive debugging than Clojure. But Clojure has so many advantages that it isn't even a close contest. Also, most of the code I write today isn't hosted on the JVM, it runs in the browser. Or gets compiled to both JVM bytecode and highly optimized JavaScript.
- fiddlerwoaroof 8y ago
  The more I've used Clojure, the less I've liked it: protocols don't work correctly, multimethods are badly designed, core.async isn't source-compatible between CLJ/CLJS, unless you know what to avoid, etc. As far as interactive development compromises go, I'm mostly thinking about how in Clojure, it seems like the only practical way to load your new code is to use something like tools.namespace/refresh (or whatever it is). And, that essentially involves throwing away everything and rebuilding it from scratch: while that has some nice properties (e.g. you don't end up with an inconsistent image state), it's also really annoying because you have to restart all your servers, etc. And, the other thing that makes CL standout from every system I've used except Smalltalks, is that Quicklisp loads third party systems into the current image without restarting: there are a bunch of tools I've seen floating around that claim to be able to do this for Clojure, but I've never really been able to make any of them work consistently.

jwr 8y ago

I had similar feelings in the very beginning, but I was quickly won over (I didn't see compromises in interactive development, though, unless you mean difficult debugging because of lazy sequences). Debugging in general was something I missed the most (after all, even in CL, I implemented return-from-frame in CMUCL to get better interactive debugging). And to this day I think CL has better interactive debugging than Clojure. But Clojure has so many advantages that it isn't even a close contest. Also, most of the code I write today isn't hosted on the JVM, it runs in the browser. Or gets compiled to both JVM bytecode and highly optimized JavaScript.

fiddlerwoaroof 8y ago
The more I've used Clojure, the less I've liked it: protocols don't work correctly, multimethods are badly designed, core.async isn't source-compatible between CLJ/CLJS, unless you know what to avoid, etc. As far as interactive development compromises go, I'm mostly thinking about how in Clojure, it seems like the only practical way to load your new code is to use something like tools.namespace/refresh (or whatever it is). And, that essentially involves throwing away everything and rebuilding it from scratch: while that has some nice properties (e.g. you don't end up with an inconsistent image state), it's also really annoying because you have to restart all your servers, etc. And, the other thing that makes CL standout from every system I've used except Smalltalks, is that Quicklisp loads third party systems into the current image without restarting: there are a bunch of tools I've seen floating around that claim to be able to do this for Clojure, but I've never really been able to make any of them work consistently.