Hacker News Reader

Comment by nlh | Hacker News Reader

Forgive me for asking what may be a very stupid question: Can someone explain to me the need for a Ruby interpreter built on top of Python? He mentions performance in the announcement, but is this really going to be faster than, say, MRI? Thanks in advance.

View on HN

Think of Pypy as somewhat like LLVM, except the language it's built on is a subset of the python language, called RPython.

Although the most well-known language implemented in the pypy "vm" is python, the toolchain is completely language agnostic.

So, this is more akin to Apple writing a C interpreter on top of llvm than it is to building a ruby interpreter on top of python.

PyPy is totally not like LLVM in many regards. It targets a very different demographics. Some differences:

* RPython comes with a good garbage collector

* the language where you specify what's going on is RPython in which you write an interpreter. Then you get a JIT using a few hints. This is difference than "interpreter in C + compiler to LLVM" scenario by quite a bit.

* RPython comes with a set of data structures that are higher level (lists, dicts, etc.) and is a GCed language. JIT is also well aware of those.

Do you know what an analogy is?

There's no need to be a jerk.

Yeah, although there may be other ways to phrase your admonishment which people will be more receptive to.

"C'mon dude, don't let flaming beget flaming."

I'm actually not a native speaker, so indeed, I might not know. I checked in the dictionary though. This is an analogy, but not a very good analogy, because of the reasons that I pointed out. Are you disagreeing with any particular reasoning there? Or should I just say "they're similary, but"?

Well, so you're right and you're wrong.

You're right that the analogy doesn't quite capture everything here. On the other hand the analogy gets across most of the point.

I would have said "That's mostly right, but the interesting thing about sharing code on a VM is access to VM features and code shared on the platform, not just that it's possible to decouple a front end from a VM."

or something to that effect.

"They're similar, but" is much better than "is totally not like." The point of the analogy is to give a high-level view, not to achieve 100% accuracy at the lowest levels of detail.

An analogy does not require that the items involved actually be similar, only that the relationships in each are the same. For example, "Gasoline is to cars, as sunlight is to trees" is a perfectly good analogy, even though gasoline is nothing like sunlight, and cars are nothing like trees.

In much the same way, comparing "Apple writing a C interpreter on top of llvm" to "Alex Gaynor writing a Ruby interpreter on top of RPython" makes a very good analogy, even though Apple is not much like Alex Gaynor, Ruby is not much like C, and PyPy is not much like LLVM.

A good explanation, and further, many times a good analogy relies on the things being very different in every way except for the one way it intends to emphasize. An analogy is often a way of saying: "Let's focus on this (often very abstract) aspect of interesting similarities. Yes, you can easily point out many other dissimilarities. That ease means I'm not talking about those aspects, so if we understand each other those don't even have to be mentioned."

I do, but I also appreciate further distinction between pypy and llvm in this context.

Completely true, I was just trying to convey how different "building ruby on RPython/Pypy" is from "building ruby on top of python".

So its closer to JVM than LLVM (http://stackoverflow.com/questions/454720/what-are-the-diffe...)?

Not really. The LLVM analogy does capture the toolchain aspect; the RPython toolchain generates a JITted VM from an interpreter description.

Thanks for that simplified explanation. As someone not familiar with Python and Pypy I was having a tough time getting past the "Ruby on Python is efficient?" block; the analogy to LLVM is helpful indeed.

RPython is a subset of Python that is used to build PyPy. If you want more information on it, I would do some reading on the structure of PyPy.

To be clear, this isn't "Ruby running on top of Python." This is "Ruby specified in RPython."

So, lets talk about JRuby. JRuby is a Ruby implementation on the JVM, and its really awesome power is actually that you can wrap and interface with Java libraries, and still write all of your app code in Ruby.

If Topaz was able to give me the ability to access NLTK, but still write in Ruby? I'd be overjoyed.

So that would be a very cool project to merge python <-> ruby (or any other interpreter written in RPython). It requires quite a bit of work to pull it off the ground though. I would be happy to provide guidance on that, but I definitely won't do it myself (just yet).

It's also worth noting that this is (mostly) possibly with RubyPython running in Ruby against a CPython2 dynamic library.

Zach Raines did 99% of the heavy lifting (I've got a very small part to the whole project, and no time to work on it right now), and it works pretty nicely overall.

> If Topaz was able to give me the ability to access NLTK

I doubt that's going to happen. Topaz is not a Ruby running on the CPython interpreter, the Topaz VM is developed in RPython. As far as I know, RPython doesn't provide that capability either (between VMs coded in RPython), which fijal seems to confirm.

Yes, because it's actually implemented on top of PyPy, which is a very modern run-time with a state-of-the-art JIT and good garbage collectors.

It's not vanilla Python but RPython, and presumably to take advantage of the PyPy toolchain to get similar results in Ruby as PyPy has in Python.

Reply on news.ycombinator.com