Hacker News Reader

Comment by frig8 | Hacker News Reader

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.

View on HN

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.

(Pedant warning)

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

It's fairly clear in the context that he's using O(x) in the informal 'order of' meaning: 'order of 10', 'order of 1000' etc.

I agree, and had no problem understanding his intended meaning but I was irked by the unnecessary misuse of technical notation to attempt to get across an idea that would have been perfectly easy to write without it (e.g., "10 times" and "1000 times").

Haha, thanks for the warning. I am reminded of another time I ended up abusing the Landau notation in a numerical analysis class ( was it probability?) some years ago. The homework was to get and N^2log(N) algorithm of some kind, but I became concerned about certain large constant factors which I could determine exactly. However, these constant factor could be written as a series in another parameter, which I couldn't approximate in a certain limit and... well, you see where I'm going. There where lots of O's with slightly different semantics on the same paper.

The interesting thing about python is that while it's fast to start, it can be slow to stop. I've certainly seen that in CPython, I don't know if it's something that affects PyPy as well.

Reply on news.ycombinator.com