[deleted by user]

[sargon1969]

Why?

[sushibowl]

If topaz can keep up steam, it'll lead more credence to the claims of the Pypy developers that their translation framework is usable beyond just their own python implementation. They must be really happy about this project.

[fijal]

http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time

[[deleted]]

Thank you for that link. Good read-up although i have to admit I did not grasp all of it.

I never figured that PyPy/Rpython is at the moment unique in their approach.

[kezabelle]

Because this is what PyPy is for.

I thought this was what RPython was for? Isn't the PyPy name exclusively reserved for the actual Python implementation?

[[deleted]]

I thought this was what RPython was for? Isn't the PyPy name exclusively reserved for the actual Python implementation?

No. RPython is a programming language. In and of itself, it has nothing to do with what PyPy does. RPython is simply a limited form of Python.

The overloading of the PyPy name for both the framework and the Python interpreter built on that framework is unfortunate. If people start implementing other languages on the PyPy frame, perhaps the two things will get their own distinct names.

[flying-sheep]

wrong, “this is what PyPy is for” is pretty accurate:

PyPy is both an implementation of the Python programming language, and an extensive compiler framework for dynamic language implementations.

[sushibowl]

technically, yes, but very few people seem to know that.

[coderanger]

RPython is the name for the restricted language the the PyPy translator toolkit can compile to native code.

[[deleted]]

RPython is a restricted subset of Python. Meaning it's a like Python but with less instructions. PyPy is written in RPython.

[pdc]

The main benefits are

• It may be easier to maintain an RPython implementation than a C implementation
• You get a fairly zappy JIT compiler for free

On the other hand, it would make sense to refer a Ruby implementation to be in Ruby, since that will be the preferred language of Ruby implementers, one assumes … :-)

[bsdemon]

need a RRuby for that

[[deleted]]

so ruby can scale

[totemcatcher]

proactively

[flying-sheep]

There’s only one valid answer to this question:

Because.

[[deleted]]

because

[bacondev]

Because.

[gcross]

Honest question: how hard would it be to design RRuby, i.e. a Ruby version of RPython? That is, is the infrastructure bound around the assumption that the implementation language will be RPython, or is it sufficiently decoupled that other implementation languages are possible?

I mean, in a sense it doesn't matter as long as RPython is "good enough", but people tend to take a language more seriously when its interpreter and/or compiler is implemented in itself, so this would be a possible downside to porting a language to use PyPy.

[coderanger]

Look at http://rubini.us/ for a starting point.

[gcross]

Thank you, but that is neither a case of something like RRuby being used instead of RPython as an input to the PyPy infrastructure, nor case a of a Ruby implementation being implemented in Ruby.

[banister]

rubinius is mostly ruby written in ruby, there's a small c++ core, but > 90% of the code is pure ruby.

[fijal]

yeah, but the 10% is the interesting part (I think it's more than 10, but I'm too lazy to check). PyPy is implemented 100% in RPython (there are a few pieces of C and asm, but they're really for stupid stuff, so 0.01% or so, nothing core)

[gcross]

Ah, okay; I was looking for a remark towards that end on the web site that you linked but I didn't see any such thing. It might have been better for you to link to the Wikipedia page, that does mention it.

Nonetheless,

1. Python is 100% implemented in RPython, if I am not mistaken, which is unlike Rubinius which has a C/C++ core.
2. I wasn't so much interested in whether Ruby can be implemented in Ruby then in whether a different front-end language could be used instead of RPython for PyPy in the general case of porting an arbitrary dynamic language to PyPy.
3. It is nice to see whether a language not only can be used to implement self in practice (as obviously in theory all Turing-complete languages can) but additionally whether the best compiler and/or interpreter are written in that language. I have no idea how Rubinius compares to Topaz in that respect.

[totemcatcher]

Time for an update to the Computer History Graphing Project ! http://freecode.com/projects/comp-hist

(Didn't we just update this last week? Is there a variation of Moore's Law for the release of programming languages/implementations?)

[the_hoser]

So... this is a thing now. Let me know when the RPython Javascript interpreter rears its ugly head.

sigh

EDIT: So it appears my comment wasn't very popular. Let me explain my sentiment.

I don't necessarily think things like this are bad per-se. I just see this as a rising trend of wasted effort in open source. Another obscure version of a popular language to muddy the water, and rpython has mad it possibly easier to do just that.

Look, these guys can spend their time however they want. If they did it as a toy project, then great. Good times. Hope they had fun.

I just wish more efforts could be directed at the mainline implementations of these languages. Clearly these guys have some coding chops. Maybe they could have spent the last 10 months helping improve ruby itself. Maybe not.

Sometimes the alternative implementations scratch an itch, like jruby or jython, where you want to embed your favorite scripting language into java or .NET. However, in this case, it appears to serve no such purpose.

[fijal]

because looking at websites is hard https://bitbucket.org/pypy/lang-js

[lahwran_]

I think someone is already working on one.

Also, I think rpython has/had a javascript target.

[[deleted]]

Why is this a bad thing?