Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure Implemented in Pure Python

github.com

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Clojure Implemented in Pure Python

#21

Post by mattdeboard »

halgari wrote: post #18
mattdeboard wrote: post #16

Earlier quoted context omitted.

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…

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,…

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.

Re: Clojure Implemented in Pure Python

#22

Post by halgari »

mattdeboard wrote: post #21
halgari wrote: post #18

Earlier quoted context omitted.

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,…

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.

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 ;-)

Re: Clojure Implemented in Pure Python

#23

Post by mattdeboard »

halgari wrote: post #22
mattdeboard wrote: post #21

Earlier quoted context omitted.

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.

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 ;-)

Well, don't get me wrong, I love Clojure and have been writing more Clj than Py the last few weeks.

Re: Clojure Implemented in Pure Python

#24

Post by halgari »

halgari wrote: post #19
ericmoritz wrote: post #17

Here's a quick benchmark on my machine (a EeePC 1001HE). I used reduce1 with clojure-py because there doesn't seem to be a reduce BIF. I don't know if that effected this benchmark any: Python: (time (reduce1 + (range 100000))) Elapsed time: 3882.57193565 msecs 4999950000 PyPy: user=> (time (reduce1 + (range 100000))) Elapsed time: 259.984970093 msecs 4999950000 Clojure via Java Hotspot: user=> (time (reduce + (range…

Those numbers a re bit small to get a full view of the way the pypy jit works: user=> (time (reduce1 + (range 100000))) Elapsed time: 903.011083603 msecs 4999950000 user=> (time (reduce1 + (range 1000000))) Elapsed time: 777.748823166 msecs 499999500000 user=> (time (reduce1 + (range 10000000))) Elapsed time: 8764.57095146 msecs 49999995000000 user=> Clojure via hotspot: user=> (time (reduce + (range 100000))) "Elaps…

Here's a blog post explaining the issues involved in a bit more detail: http://clojure-py.blogspot.com/

Re: Clojure Implemented in Pure Python

#26

Post by halgari »

DanielRibeiro wrote: post #25

Former discussion on HN: http://news.ycombinator.com/item?id=3589374

PyClojure (in the link) didn't actually take it to the extent we are. clojure-py goes so far as to implement all the standard collections in pure python. So [1 2 3] in clojure-py is a PersistentVector not a python list.

Re: Clojure Implemented in Pure Python

#27

Post by frig8 »

This is an exciting idea, but I think the home page focuses far too much on these hypothesized advantages of a dynamic VM. Not only are the advantages unproven, it's hard to see how this project represents anything novel in that aspect given that ClojureScript already exists.

The things that come to my mind are things like Numpy, Scipy, PySide, boost.python and all other sorts of Python bindings to C, C++ and Fortran code that aren't readily available on the JVM. Also, the startup time that the JVM can't match, the Python standard library and the other random bits people have developed that make Python such a wonderfully flexible scripting environment.

If you have excellent interop, there will be plenty of interest in this project regardless of how fast or slow it is. If it's fast, all the better.

Re: Clojure Implemented in Pure Python

#28

Post by omaranto »

mattdeboard wrote: post #21
halgari wrote: post #18

Earlier quoted context omitted.

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,…

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.

Consider the case of a person that prefers programming in Clojure to programming in Python... :)

Re: Clojure Implemented in Pure Python

#29

Post by gajomi »

frig8 wrote: post #27

This is an exciting idea, but I think the home page focuses far too much on these hypothesized advantages of a dynamic VM. Not only are the advantages unproven, it's hard to see how this project represents anything novel in that aspect given that ClojureScript already exists. The things that come to my mind are things like Numpy, Scipy, PySide, boost.python and all other sorts of Python bindings to C, C++ and Fortran…

I agree. Native access to legacy linear algebra functionality exposed by Numpy is the #1 reason this project seems exciting to me. I don't really care if the bulk of the code is O(10) slower so long as the numerical bits are O(1000) faster, which is a typical comparison of LAPACK for the JVM equivalents.

Re: Clojure Implemented in Pure Python

#30

Post by ScottBurson »

Huh. I think Common Lisp would be a much better choice than Python. It's much faster, for starters. And it lets you do some fairly low-level stuff if you want.

In general I think Common Lisp's virtues as an implementation substrate for other languages are much greater than most people appreciate. It is flexible, expressive, and fast. Its dynamicity comes in very handy. And some of its vices -- its sheer size, its lack of orthogonality, and its occasionally archaic naming conventions -- are much less problematic for a language implementation task than they are for general programming.

There are exceptions, of course. You wouldn't want to implement C++ in Common Lisp. But for dynamically typed languages it ought to be a leading candidate.

Post reply on HN