Clojure Implemented in Pure Python
github.com
github.com
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.
I think you may be abusing Big-O notation a little here since, technically O(10) is equivalent to O(1000)—and both are O(1).
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.
Basically it reflection (aka dynamic dispatch) is a major performance killer if you don't implement a tracing jit.
That said, a good tracing JIT is probably better; but on the other hand, SBCL has profited from many years of optimization work on CMU CL. It would be interesting to see some real-world performance comparisons between SBCL and PyPy.
If you want to do lisp programming with CL libraries, you could just use CL.
I'm not sure what the advantage of clojure in CL is over just using CL.
Python:
(time (reduce1 + (range 100000)))
Elapsed time: 3882.57193565 msecs
4999950000
user=> (time (reduce1 + (range 100000)))
Elapsed time: 259.984970093 msecs
4999950000
user=> (time (reduce + (range 100000)))
"Elapsed time: 75.35225 msecs"
4999950000 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)))
"Elapsed time: 174.768593 msecs"
4999950000
user=> (time (reduce + (range 1000000)))
"Elapsed time: 267.60421 msecs"
499999500000
user=> (time (reduce + (range 10000000)))
"Elapsed time: 1131.77367 msecs"
49999995000000
user=>
Atoms, refs and agents seem like an integral part of the Clojure language however.
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.
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.
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.
Truth is, you only need one, as long as it's a good one.