Fructose: compile Ruby into PHP
fructoselang.org
fructoselang.org
Yes it says Mono is supported, but why? Windows is the least run environment for either of these languages (Ruby / PHP). Were I to guess, I'd say this was a dare that it couldn't be done, and if that's the case, then hats off to the owner for doing it.
Now that would be perverse.
* mixins
* classes are objects
* eigenclasses
* method_missing, respond_to, respond_to_missing, send, super
* splat
* extended, included, inherited callbacks
Converting programming languages really doesn't serve any purpose whatsoever - this can't be used as a learning tool (a rubyist wanting to learn php) nor should this output ever be trusted in a production environment as you are going to count on the converted code being as efficient as your original code.
If you want to code in PHP, use PHP - if you want to code in Ruby, use Ruby - this just seems silly.
I'm guessing you don't use a lot of programs written in C?
* Running multiple languages (each with it's own strengths) on platforms that natively support only a few languages. e.x. GWT, CoffeeScript.
* Enhancing an existing language. e.x. Objective-J, Stratified JavaScript.
* Performance. e.x. HipHop for PHP.
* Quickly building new languages. Objective-C (and I think C++?) was originally just a preprocessor for C.
That said, I personally don't find a Ruby-to-PHP compiler particularly useful. Maybe it could be useful for running Ruby on the ubiquitous and cheap Apache/PHP shared hosts, but I suspect the overhead of loading a large amount of code (even just Ruby's standard library, let alone Rails) on each request will make that infeasible.
While this may be a valid arguement for some - I just can't accept it - if you are targeting a specific platform you really should (completely imho) use the tools meant for it. Anything else will easily lead to issues that may not be debug-able if you aren't already familiar with your target.
Enhancing an existing language. e.x. Objective-J, Stratified JavaScript.
Both of these enhance an existing language by creating a interpreted scripting language that gets compiled down by the original language. I wouldn't classify these as a source-to-source compiler imho.
Performance. e.x. HipHop for PHP.
HipHop is indeed a good example and I stand corrected there. The slight difference is that this is specifically targetted at creating highly optimized C++ to be compiled for quicker execution. In a Ruby-to-PHP example it's certainly not going to add performance gain and is a silly idea - but as I said, I didn't think about a valid execution like HipHop in my initial blanket statement.
Quickly building new languages. Objective-C (and I think C++?) was originally just a preprocessor for C.
I didn't even think about preprocessors and they are indeed another valid implementation for source-to-source compilation.
My original statement was a bit too quickly posted - thanks for the correction!
And you're also discounting the possibility that somebody might know multiple languages well enough to support the generated code (as is usually the case for CoffeeScripters) but are more productive one language for certain tasks.
By that logic, since my processor doesn't natively run Ruby, I should be coding in machine language.
I can't speak for CoffeeScript yet, but the front-end developer who sits near me is using SCSS to generate CSS for our web pages, and he is able to do things that wouldn't be practical with plain CSS. For example, change a base color variable from blue to green, and have all the other colors on the page adjust to use complementary colors.
If you trust Ruby to produce reliable C code and C to produce reliable assembly code, etc, isn't it possible that Coffeescript could produce reliable Javascript? Mightn't it give you advantages like Ruby gives you over plain C? I think this is less a matter of "compiling X to Y is good/bad" than "do I trust this particular conversion to be done correctly?"
As far as compiling Ruby to PHP - well, I can't see any use for that at the moment, but I'm sure someone will come up with one. :)
Java can be compiled via gcj ("It [GCJ] can compile Java source code to Java bytecode (class files) or directly to native machine code, and Java bytecode to native machine code." - http://gcc.gnu.org/java/). C# can be compiled down to native code using various tools. MonoTouch uses that to run C# on iPhones for example.
class Greeter {
public static function greet($text) {
echo $text;
}
}
Greeter::greet("Hello, World!\n"); class Greeter {
public function __construct($fn) {
$this->greeting = $fn();
}
public function greet() {
echo $this->greeting;
}
}
$greeter = new Greeter(function() {
return "Hello, World!";
});
$greeter->greet();
There's a reason the Fructose generated PHP isn't very pretty. The Fructose generated code will run on any version of PHP that's at least 5.0.
I like the implications of the name. Fructose - it's kinda sweet but not quite real sugar, and there's a suspicion of some deep and not-quite-right subterfuge going on underneath the entire industry that supports it for no real reason...
But still, fun project to see.
(Did I just feel all of the HN rubyists shudder at once?)
Yes. So, do you really want him writing PHP?
1 - Writing the example in PHP from scratch would be at least as simple as writing it in Ruby, it's only because it's been converted that the PHP code is so convoluted.
2 - Depending on what you consider a to be 'small' app, PHP is probably the better language. I find Ruby is more suited to larger scale apps, especially where persistence is advantageous.
In short, Fructose is just going to give PHP more undeserved bad press.
First, HipHop doesn't support create_function, which is used in the example.
Second, feature mismatch between Ruby and PHP will make efficient compilation quite hard and most likely be far from optimal. The languages doesn't seem to be very easily optimizable either.
HipHop isn't a silver bullet either: sometimes it seems to be faster than cached PHP bytecode, but not always.
Active community participation too =).