6 ms·

> but as a LISP most people aren't going to be excited about using it. I agree that Clojure has a lot of strong points and that s-expressions probably put a lo

by kbp 8y ago

> but as a LISP most people aren't going to be excited about using it. I agree that Clojure has a lot of strong points and that s-expressions probably put a lot of people off, but as a Lisp programmer, I was very disappointed in Clojure's debugging/interactive development story (and I've heard that from a lot of others). It feels more like using a typical scripting language compared to the traditional Lisp/Smalltalk experience, and even there, a typical scripting language would at least give useful backtraces. As it stands, I think a decent number of conventional Lisp programmers would also worry about large Clojure programs being unmaintainable unless they're superbly written.

diab0lic 8y ago
Oh, yes this is another excellent example of pain while building Clojure code bases. Though I'll say I only agree with half of your statement. I've found the interactive development story to be great with nrepl/fireplace/vim but the debugging is downright terrible... this is the single biggest blocker to me using it for larger systems.
- michaelmrose 8y ago
  Debugging seems acceptable on emacs with cider. Sayid seems interesting as well.
  - fiddlerwoaroof 8y ago
    Yeah, cider has an amazing form by form debugger for Clojure. And the way cider uses overlays to surface this is quite nice too. My general experience of cider is that for a certain set of tasks it is much better than slime. But, the problem is, most of my day-to-day coding tasks are hampered by the language: e.g. if I have a web server running and I want to change a request handler, you can’t just recompile the handler, you also have to restart the server.
    - fiddlerwoaroof 8y ago
      (Although, if you anticipate this, you can call the ref (e.g. `(#’foo arg)`) rather than the function `(foo arg)`. But this means that you have to plan the dynamically modifiable parts out ahead of time.
      - unlogic 8y ago
        That's not true. You only have to prepend #' if you pass the function by value (as in your web server handler example). If you call the function by name yourself, like (foo arg), and you recompile foo, any code that called foo will see the new version.
        fiddlerwoaroof 8y ago
        Hmm, I’ll try it again, but I remember issues with the function call syntax too. Iirc, it had to do with the fact that redefinitions don’t count if the use site is running in another thread. But I’ll double-check this when I get a chance.
flavio81 8y ago
> I was very disappointed in Clojure's debugging/interactive development story (and I've heard that from a lot of others). It feels more like using a typical scripting language compared to the traditional Lisp/Smalltalk experience Common Lisp user here. I was also disappointed in the same way when trying Clojure. Other minor things i didn't like was the noisy [] on the syntax, and the fact that for practical purposes you're fully tied to the JVM and the java runtime libs.
- kamaal 8y ago
  >>for practical purposes you're fully tied to the JVM and the java runtime libs. That's more like a positive thing about Clojure. Java inter-op and targeting the JVM gives Clojure a great chance of adoption at large enterprises. These days no one really has a issue installing jars on a production machine.
gleenn 8y ago
The latest Clojure in the pipe, 1.10, is supposed to have a lot of work done fixing stacktraces FWIW.
- diab0lic 8y ago
  I'm very happy to be reading this!
fulafel 8y ago
It's a big exaggeration to say Clojure stack traces aren't useful. They have some extra noise but they do the job of pointing out the call chain and the exception value. Tooling (CIDER at least) can automatically hide the frames about the Java runtime and highlight the Clojure info & line numbers.

by kbp 8y ago

diab0lic 8y ago

Oh, yes this is another excellent example of pain while building Clojure code bases. Though I'll say I only agree with half of your statement. I've found the interactive development story to be great with nrepl/fireplace/vim but the debugging is downright terrible... this is the single biggest blocker to me using it for larger systems.

michaelmrose 8y ago
Debugging seems acceptable on emacs with cider. Sayid seems interesting as well.
- fiddlerwoaroof 8y ago
  Yeah, cider has an amazing form by form debugger for Clojure. And the way cider uses overlays to surface this is quite nice too. My general experience of cider is that for a certain set of tasks it is much better than slime. But, the problem is, most of my day-to-day coding tasks are hampered by the language: e.g. if I have a web server running and I want to change a request handler, you can’t just recompile the handler, you also have to restart the server.
  - fiddlerwoaroof 8y ago
    (Although, if you anticipate this, you can call the ref (e.g. `(#’foo arg)`) rather than the function `(foo arg)`. But this means that you have to plan the dynamically modifiable parts out ahead of time.
    - unlogic 8y ago
      That's not true. You only have to prepend #' if you pass the function by value (as in your web server handler example). If you call the function by name yourself, like (foo arg), and you recompile foo, any code that called foo will see the new version.
      - fiddlerwoaroof 8y ago
        Hmm, I’ll try it again, but I remember issues with the function call syntax too. Iirc, it had to do with the fact that redefinitions don’t count if the use site is running in another thread. But I’ll double-check this when I get a chance.

flavio81 8y ago

> I was very disappointed in Clojure's debugging/interactive development story (and I've heard that from a lot of others). It feels more like using a typical scripting language compared to the traditional Lisp/Smalltalk experience Common Lisp user here. I was also disappointed in the same way when trying Clojure. Other minor things i didn't like was the noisy [] on the syntax, and the fact that for practical purposes you're fully tied to the JVM and the java runtime libs.

kamaal 8y ago
>>for practical purposes you're fully tied to the JVM and the java runtime libs. That's more like a positive thing about Clojure. Java inter-op and targeting the JVM gives Clojure a great chance of adoption at large enterprises. These days no one really has a issue installing jars on a production machine.

gleenn 8y ago

The latest Clojure in the pipe, 1.10, is supposed to have a lot of work done fixing stacktraces FWIW.

diab0lic 8y ago
I'm very happy to be reading this!

fulafel 8y ago

It's a big exaggeration to say Clojure stack traces aren't useful. They have some extra noise but they do the job of pointing out the call chain and the exception value. Tooling (CIDER at least) can automatically hide the frames about the Java runtime and highlight the Clojure info & line numbers.