3 ms·

That wouldn't be possible on the JVM. CL's condition system is unique to CL AFAIK. Even Emacs' cl module doesn't have this condition system. You really need sup

That wouldn't be possible on the JVM. CL's condition system is unique to CL AFAIK. Even Emacs' cl module doesn't have this condition system. You really need support from the ground up to have it. Clojure is a hosted language, CL isn't. There are loads of tradeoffs from that design decision alone. Saying it feels primitive for that difference only is jumping to conclusions rather quickly! It feels like you're comparing decades of CL experience with days of Clojure experience :)

junke 10y ago
> Clojure is a hosted language, CL isn't. CL works on the JVM too (ABCL). There is a "java" layer where you can introspect classes and create them dynamically, etc. The syntax is not as terse as Clojure one's. There is one thing that I have had difficulties to do in Clojure, for example, is when you want to abstract over types: (fn [type] (.. type (staticFunction))) As far as I know, the above doesn't work because "type" is expected to be known at compile-time.
- jeremiep 10y ago
  Didn't know about ABCL :) You have defprotocol to dispatch based on types in clojure. There's deftype to dynamically create classes and Java has reflection to begin with. You can call .getClass at runtime (which is what the type function does).
  - junke 10y ago
    Thanks
kbp 10y ago
That difference does feel primitive, though; it's like a C-style edit->compile->run cycle vs talking to a listener. Like you said, tradeoffs, and Clojure definitely has a lot of other stuff going for it, but its version of interactive development is just a lot less interactive.
- jeremiep 10y ago
  That's ignoring the REPL :) You rarely reboot a program under development in Clojure - you rather connect your editor to its network REPL and live code everything from there. This makes not having a condition system a minor inconvenience at best.
  - kbp 10y ago
    Until you get an error at the REPL.
    - jeremiep 10y ago
      Which is fixed interactively at the same REPL. You're just restarting a computation instead of resuming it. Rather than recompiling/rebooting the entire program and losing its state in the process. However, this style of development has taught me to write code that's resilient to such errors in the first place (as it, errors wont leave the program in an invalid state), and the end result is that I feel much more confident putting code in production and restarting computations at the REPL is effectively free and feels the same as using the condition system for the most part.
      - kbp 10y ago
        That's my point--you're restarting the 'computation' instead of resuming it, compared to restarting the program. It's the same benefits you acknowledge, just, moreso.
        jeremiep 10y ago
        It depends on the context. Resuming a request handler after the client timed out is no good. Even in CL in those cases you're fixing at the REPL and having the client redo the request. Or you're developing your function in a sandbox and restarting the computation has no difference to resuming it in the first place.
        10y ago
nialo 10y ago
It turns out that it is, in fact, at least mostly possible to implement a condition type system in Clojure. See https://www.youtube.com/watch?v=zp0OEDcAro0 https://www.youtube.com/watch?v=zp0OEDcAro0 I did a little bit of googling for Clojure libraries that do this: https://github.com/zcaudate/ribol https://github.com/zcaudate/ribol and https://github.com/clojureman/special https://github.com/clojureman/special I don't actually recommend any of these and haven't tried them. In particular I think using a non-standard library for your error handling, which is already probably relatively poorly tested, is probably a bad idea. I just wanted to point out that it's possible. I also think I remember something in a Rich Hickey talk (maybe "Clojure for Lisp Programmers"?) where someone in the audience asks about condition systems, and he responds that Clojure doesn't have one, but that it should be possible to build it.
- jeremiep 10y ago
  Thanks for pointing this out! I agree about being very careful in choosing to use such libraries! One concern I have is how well they integrate with the native exception system of the VM and what stopping on an error waiting for programmer input would mean in a lot of contexts. For example, stopping in a request handler while the programmer fixes the code will most likely trigger a timeout on the other end completely killing any advantage the condition system had in the first place. You've effectively bloated your programs with libraries you're not even taking advantage of :)
  - fiddlerwoaroof 10y ago
    In common lisp, during development, you can fix a surprising number of mistakes before the browser times out: especially mistakes involving things like typos. The other advantage of the condition/restart system is that it makes your libraries more reusable: rather than having either to choose one error handling strategy or to construct a system for choosing an error handling strategy, the language itself provides a construct for making several error handling strategies available that higher-level code can choose between in a straightforward manner.
lispm 10y ago
> Clojure is a hosted language, CL isn't. There is nothing in the CL standard which says a single word about it. The idea of the standard is that it is possible to have different implementations: native on some CISC/RISC/Lisp CPU, on top of C, on top of a virtual machine, on top of the JVM, using the LLWM, etc etc... > That wouldn't be possible on the JVM. CL's condition system is unique to CL AFAIK. Let's run ABCL on the JVM, on my ARM-based ODROID: Armed Bear Common Lisp 1.3.3 Java 1.8.0-ea Oracle Corporation Java HotSpot(TM) Server VM Low-level initialization completed in 1.242 seconds. Startup completed in 6.577 seconds. Type ":help" for a list of available commands. CL-USER(1): (handler-case (and (evenp 2) (/ 3 0) (oddp 1)) (error (c) (princ c) (values))) Arithmetic error DIVISION-BY-ZERO signalled. oops, it supports the CL condition system...

junke 10y ago

> Clojure is a hosted language, CL isn't. CL works on the JVM too (ABCL). There is a "java" layer where you can introspect classes and create them dynamically, etc. The syntax is not as terse as Clojure one's. There is one thing that I have had difficulties to do in Clojure, for example, is when you want to abstract over types: (fn [type] (.. type (staticFunction))) As far as I know, the above doesn't work because "type" is expected to be known at compile-time.

jeremiep 10y ago
Didn't know about ABCL :) You have defprotocol to dispatch based on types in clojure. There's deftype to dynamically create classes and Java has reflection to begin with. You can call .getClass at runtime (which is what the type function does).
- junke 10y ago
  Thanks

kbp 10y ago

That difference does feel primitive, though; it's like a C-style edit->compile->run cycle vs talking to a listener. Like you said, tradeoffs, and Clojure definitely has a lot of other stuff going for it, but its version of interactive development is just a lot less interactive.

jeremiep 10y ago
That's ignoring the REPL :) You rarely reboot a program under development in Clojure - you rather connect your editor to its network REPL and live code everything from there. This makes not having a condition system a minor inconvenience at best.
- kbp 10y ago
  Until you get an error at the REPL.
  - jeremiep 10y ago
    Which is fixed interactively at the same REPL. You're just restarting a computation instead of resuming it. Rather than recompiling/rebooting the entire program and losing its state in the process. However, this style of development has taught me to write code that's resilient to such errors in the first place (as it, errors wont leave the program in an invalid state), and the end result is that I feel much more confident putting code in production and restarting computations at the REPL is effectively free and feels the same as using the condition system for the most part.
    - kbp 10y ago
      That's my point--you're restarting the 'computation' instead of resuming it, compared to restarting the program. It's the same benefits you acknowledge, just, moreso.
      - jeremiep 10y ago
        It depends on the context. Resuming a request handler after the client timed out is no good. Even in CL in those cases you're fixing at the REPL and having the client redo the request. Or you're developing your function in a sandbox and restarting the computation has no difference to resuming it in the first place.
        10y ago

nialo 10y ago

It turns out that it is, in fact, at least mostly possible to implement a condition type system in Clojure. See https://www.youtube.com/watch?v=zp0OEDcAro0 https://www.youtube.com/watch?v=zp0OEDcAro0 I did a little bit of googling for Clojure libraries that do this: https://github.com/zcaudate/ribol https://github.com/zcaudate/ribol and https://github.com/clojureman/special https://github.com/clojureman/special I don't actually recommend any of these and haven't tried them. In particular I think using a non-standard library for your error handling, which is already probably relatively poorly tested, is probably a bad idea. I just wanted to point out that it's possible. I also think I remember something in a Rich Hickey talk (maybe "Clojure for Lisp Programmers"?) where someone in the audience asks about condition systems, and he responds that Clojure doesn't have one, but that it should be possible to build it.

jeremiep 10y ago
Thanks for pointing this out! I agree about being very careful in choosing to use such libraries! One concern I have is how well they integrate with the native exception system of the VM and what stopping on an error waiting for programmer input would mean in a lot of contexts. For example, stopping in a request handler while the programmer fixes the code will most likely trigger a timeout on the other end completely killing any advantage the condition system had in the first place. You've effectively bloated your programs with libraries you're not even taking advantage of :)
- fiddlerwoaroof 10y ago
  In common lisp, during development, you can fix a surprising number of mistakes before the browser times out: especially mistakes involving things like typos. The other advantage of the condition/restart system is that it makes your libraries more reusable: rather than having either to choose one error handling strategy or to construct a system for choosing an error handling strategy, the language itself provides a construct for making several error handling strategies available that higher-level code can choose between in a straightforward manner.

lispm 10y ago

> Clojure is a hosted language, CL isn't. There is nothing in the CL standard which says a single word about it. The idea of the standard is that it is possible to have different implementations: native on some CISC/RISC/Lisp CPU, on top of C, on top of a virtual machine, on top of the JVM, using the LLWM, etc etc... > That wouldn't be possible on the JVM. CL's condition system is unique to CL AFAIK. Let's run ABCL on the JVM, on my ARM-based ODROID: Armed Bear Common Lisp 1.3.3 Java 1.8.0-ea Oracle Corporation Java HotSpot(TM) Server VM Low-level initialization completed in 1.242 seconds. Startup completed in 6.577 seconds. Type ":help" for a list of available commands. CL-USER(1): (handler-case (and (evenp 2) (/ 3 0) (oddp 1)) (error (c) (princ c) (values))) Arithmetic error DIVISION-BY-ZERO signalled. oops, it supports the CL condition system...