One of the authors conclusions (see section 7 of the PDF) about PHP threading is 1/2 wrong. There is the PCNTL extension. And I actually wrote some code for a project of mine that does batch processing using multiple processes; my code works with vanilla PHP, unlike the PCNTL extension.
The PCNTL extension is about process control, not threading. I don't see how it could help to solve the limitations mentioned in the section 7.1 of the thesis.
Actually this page is brilliant. I have not included php.js in my projects but used this page many times to find out how to do in JavaScript things that are easy in PHP but in js ... they are not easy at all.
I saw his original presentation in Prague - Euruko 2008. Nice to see that he completed the project. Congrats dude, it's a huge project to take on. Will you be pushing the code on github?
I begun to work on the master thesis when there was no mod_rails, Rails hostings were less common and they were more expensive than PHP hostings. So the other commenters in this thread are right about the "deployability" reason.
When the work was being finished, I aleready saw that the real-world usefulness of the compiler is minimal. This is why I didn't develop the compiler further after finishing the thesis.
The likely rationale is that there's probably quite a few people who want the deployability of PHP without having to work around the problems with the language.
to be honest though, with the advent of passenger (basically mod_rails), ruby webapps don't feel harder to deploy then PHP at all any more.
I don't see any practical reason to translate Ruby to PHP. Compared to other translations, this one doesn't make sense at all as you don't get any advantages of the translations result.
Compare this to a translator that translates Ruby to JS: Here you get the ability to run Ruby in the browsers. Or JRuby where you get the ability to run Ruby in a Java-only environment (plus a bit of performance in some cases), or IronRuby for the same reasons for the .NET platform.
It might not be impossible to set up, but there are far more webhosts that offer php than rails (and believe it or not, there are plenty of people who are in the market for $2/month webhosting).
I have a feeling that the time to make a rails application transcoded to PHP actually work on a $2/month hoster amounts to much more money than a rails hosting plan, which, after googling for "rails hosting" seems to be available for $4/month.
So unless your time is really cheap ($2/month, that's, considering a 40 hours week $0.0125/hour), you'd be better off just getting a rails hoster.
No. This feels like it's of pure academical value.
Going back to using PHP after extensively using ruby is pretty brutal, even with just a subset of the functionality, this is a pretty nice little project, imo. Maybe one of us will drag it back from the grave.
As a Ruby developer, a fully working 100% Ruby->PHP doodad would interest me for ease of deployability (Passenger rocks, but it's hardly universal) and speed. PHP still kicks even Ruby 1.9's ass on the Alioth speed tests. I wonder if PHP (or even Zend) can act as a good virtual machine of sorts in the way the JVM does..
