5 ms·

Er, what about Java interop? The notions of atoms, agents and refs? How are you going to translate these into "pure Python"?

dkersten 15y ago
CLR Clojure doesn't have Java interop either. Neither does clojurescript. I don't think its a requirement for a Clojure implementation. Atoms, refs and agents seem like an integral part of the Clojure language however.
- mattdeboard 15y ago
  I have to admit I'm not hip to all the newfangled doings with alternative Clojure targets. To me though java interop is one of the core differentiators for Clojure from other langs aside from its lispness. But, you're right, it's not required.
- halgari 15y ago
  There's absolutely nothing stopping us from implementing atoms, refs, and agents on clojure-py. Sure, the GIL won't help at all, but PyPy is working hard to fix that.
  - mattdeboard 15y ago
    Is this a hobby project or are you aiming toward getting adoption? I will confess that I don't understand the point. If we accept the Church-Turing thesis then there's no reason that by the time you catch up to Clojure's performance on the JVM it will have been optimized beyond the measurement you made. The only real guarantee you can make is that you will have added an abstraction layer to Python. While I definitely think this is a cool project, when I think about using it in production it strikes me as more Sisyphus than Prometheus.
    - halgari 15y ago
      First of all, it should be mentioned, that this is not an abstraction layer. Clojure-py functions are actual Python functions (not classes as they are on the JVM). This means that the speed of clojure-py is almost exactly the same as python code. Secondly, there is some benifit to not having to worry about static typing in a dynamic language. Anyone want to explain how to read a binary file in Clojure? Here's a hint, it takes the use of FileInputStream, DataInputStream. In clojure-py it's as simple as (py/open "foo.bin" "r"). And thirdly, why are we writing a dynamic language on a static VM? Fast Clojure code on the JVM these days takes little hints. You have to tag parameters with ^Integer and ^Double to kick the compiler type inference into gear. None of this is required on a dynamic VM. In fact, it's completely pointless.
      - deleted 15y ago
        [deleted]
      - mattdeboard 15y ago
        Ok, what's the use case? What is the benefit to this versus regular ol' Python? In what situations might I write clj-py assumine identical performance to Cpython or pypy, instead of just Python? I agree that this is a really cool project and I plan on reading through the source when I have time strictly as a learning exercise, but I cannot think of a use case.
        halgari 15y ago
        I agree, if you're into Python, use python. However, I find things like macros, protocols, and multimethods drastically reduce the amount of coding that has to be done to accomplish a certain task. But I'm biased there ;-)
        mattdeboard 15y ago
        Well, don't get me wrong, I love Clojure and have been writing more Clj than Py the last few weeks.
        omaranto 15y ago

dkersten 15y ago

CLR Clojure doesn't have Java interop either. Neither does clojurescript. I don't think its a requirement for a Clojure implementation. Atoms, refs and agents seem like an integral part of the Clojure language however.

mattdeboard 15y ago
I have to admit I'm not hip to all the newfangled doings with alternative Clojure targets. To me though java interop is one of the core differentiators for Clojure from other langs aside from its lispness. But, you're right, it's not required.
halgari 15y ago
There's absolutely nothing stopping us from implementing atoms, refs, and agents on clojure-py. Sure, the GIL won't help at all, but PyPy is working hard to fix that.
- mattdeboard 15y ago
  Is this a hobby project or are you aiming toward getting adoption? I will confess that I don't understand the point. If we accept the Church-Turing thesis then there's no reason that by the time you catch up to Clojure's performance on the JVM it will have been optimized beyond the measurement you made. The only real guarantee you can make is that you will have added an abstraction layer to Python. While I definitely think this is a cool project, when I think about using it in production it strikes me as more Sisyphus than Prometheus.
  - halgari 15y ago
    First of all, it should be mentioned, that this is not an abstraction layer. Clojure-py functions are actual Python functions (not classes as they are on the JVM). This means that the speed of clojure-py is almost exactly the same as python code. Secondly, there is some benifit to not having to worry about static typing in a dynamic language. Anyone want to explain how to read a binary file in Clojure? Here's a hint, it takes the use of FileInputStream, DataInputStream. In clojure-py it's as simple as (py/open "foo.bin" "r"). And thirdly, why are we writing a dynamic language on a static VM? Fast Clojure code on the JVM these days takes little hints. You have to tag parameters with ^Integer and ^Double to kick the compiler type inference into gear. None of this is required on a dynamic VM. In fact, it's completely pointless.
    - deleted 15y ago
      [deleted]
    - mattdeboard 15y ago
      Ok, what's the use case? What is the benefit to this versus regular ol' Python? In what situations might I write clj-py assumine identical performance to Cpython or pypy, instead of just Python? I agree that this is a really cool project and I plan on reading through the source when I have time strictly as a learning exercise, but I cannot think of a use case.
      - halgari 15y ago
        I agree, if you're into Python, use python. However, I find things like macros, protocols, and multimethods drastically reduce the amount of coding that has to be done to accomplish a certain task. But I'm biased there ;-)
        mattdeboard 15y ago
        Well, don't get me wrong, I love Clojure and have been writing more Clj than Py the last few weeks.
      - omaranto 15y ago