From: Roger Pack <rogerpack2005@...>
Date: 2009-01-03T07:44:29+09:00
Subject: Re: ruby -> python

> I think that, in the long run, it would be nice to have ruco (or 
> whatever
> the Ruby equivalent of psyco would be called) anyway -- so, if you're
> going to go to the effort of writing code intended to lead to runtime
> optimization, you might want to consider just doing it "right" in the
> first place.

Yeah--I'm looking for the easiest path here--like from the outside it 
seems like a "ruco" project is two-fold: one get a working JIT 
compilation working [arguably non-trivial] and then get it to work with 
different parameters.  Whereas "rupy" seems like one step.

Psyco itself has a large download from what appears to be "lots of lines 
of code"[1], which made me think that "ruco" is hard and "rupy" might be 
simpler.  At least I can write rupy in Ruby theoretically, which seems 
faster and easier than C.

> On the other hand, I can see potential benefits of having a (preferably
> two-way) translator between Ruby and Python for a lot of common-case
> code, regardless of whether it ever gets used for Ruby psyco support. 
What would the benefits be?

I suppose that being able to convert to Python might help with the 
google app engine or what not.

> As
> such, again, if you're intent on doing it that way I'd say get involved
> in a Ruby-Python/Python-Ruby "compiler" and do *that* right, then
> eventually use it as the basis for psyco runtime optimization of Ruby
> code if nobody has gotten around to writing ruco-or-whatever by then.

By compiler you mean it translates a .rb file to a .py one? [or like 
unholy bytecode -> bytecode]?


> Of course, I'm not really sold on the idea that automating translation
> between Ruby and Python (especially the Ruby->Python part) would be
> notably easier than compiling Ruby to C.  Ruby has capabilities that the
> Python core developers deliberately eschew, after all, because of the
> whole "the way we do it is the *right* way" design aesthetic in Python
> circles.  If you start opening core classes, metaprogramming, or working

No joke.  Just the thought of having to use len(instance) instead of 
string_instance.length makes me cringe LOL.

My hope was that Python and Ruby would be similar enough to make it 
easy.  In which I'm probably sadly mistaken but...it might still be an 
interesting project.  I think I may well end up just living with 1.9's 
[slightly improved] speed :)

Thoughts?

-=r
[1] http://codespeak.net/svn/psyco/dist/c/

Psyco v. 1.9 speeds: 
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=psyco&lang2=yarv
-- 
Posted via http://www.ruby-forum.com/.