Hacker Newsnew | comments | show | ask | jobs | submit login
Fructose: compile Ruby into PHP (fructoselang.org)
127 points by cygwin98 1489 days ago | 52 comments



What makes this project even more incredible is the fact that it's written in C# under .NET 4.0 using IronRuby for the parser.

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.

-----


Somewhat related: One RubyConf, zenspider and tenderlove hacked together Phuby on Phails, an abomination that allowed you to use PHP within Rails. It even translated instance variables from Rails controllers to PHP views.

http://www.youtube.com/watch?v=lsWKjS6Vufw

-----


Upvoting for sheer perversity.

-----


Well, this is only half the battle. The rest of it should be that it's running on a stack of apple //e motherboards.

Now that would be perverse.

-----


seeing the PHP monstrosity Ruby has as an equivalent straightens my feelings of what an ugly language Ruby in it intrinsic nature is

-----


You realize that this logic can be applied, in reverse, to make a similar conclusion about PHP, right? Seeing the monstrous PHP code that equates to simple Ruby statements confirms my feelings about what a poorly designed language PHP is. (For example)

-----


This is an unavoidable part of compilation; there's no way a compiler could write code as well as a human. It applies to all compilers; a human programmer writing assembly language would be hard-pressed to understand the output of a C compiler.

-----


totally agree with that statement, look at the massive output in php vs the simple readable rb code

-----


yes, i understand, Friday, end of the week, the humor storage got depleted somewhere around Wednesday.

-----


Projects like these are awesome learning experiences. I've been working on something similar (rubyisms in php) but in pure php - https://github.com/shuber/phuby

  * mixins
  * classes are objects
  * eigenclasses
  * method_missing, respond_to, respond_to_missing, send, super
  * splat
  * extended, included, inherited callbacks
Definitely made me appreciate ruby more after working on it.

-----


Besides being a fun side project and having a chance to play with lexical parsing - does this have any point?

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.

-----


There are plenty of reasons to use source-to-source compilers (which is what I assume you meant by "converting programming languages")

* 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.

-----


Running multiple languages (each with it's own strengths) on platforms that natively support only a few languages. e.x. GWT, CoffeeScript.

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!

-----


That's about as sensible as saying that languages that compile to machine code are impractical because you can't read machine code on all the platforms where you're going to deploy. Which is every language, ultimately.

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.

-----


"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."

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. :)

-----


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.

I'm guessing you don't use a lot of programs written in C?

-----


C++ started out as a precompiled language, and I love CoffeeScript, which compiles to JavaScript. Java and C# don't compile all the way down to assembly either. There are plenty of reasons to compile one language to another.

-----


Both Java and C# can be compiled to native binaries - there's nothing stopping that. The standard runtimes for them just don't do that.

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.

-----


Java/C# are different in that they compile to a bytecode which is like vm assembly its also not meant as a high level programming language(note that this isn't always compiled to assembly at the end as it can be interpreted, standard java for instance does both jit and interprets for best results).

-----


"Converting programming languages really doesn't serve any purpose whatsoever" Compilers are useful. This probably won't reach production quality but that doesn't mean it couldn't with the right effort, see hip-hop or one of those x-> javascript compilers.

-----


The only reason this seems at all useful would be to take advantage of cheap shared hosting that can only run php. But that's hardly a good reason given that you can run a ruby (rack-based) app on heroku for free!

-----


I've had consulting gigs where I was forced to write PHP apps because of management decisions. Something like this would have been helpful.

-----


I'm guessing that your clients wouldn't be pleased with the PHP the compiler produces. It wouldn't really be maintainable PHP code for them.

-----


Just tell them it's really good PHP.

-----


There's a Poe's Law joke buried here somewhere.

-----


Thats a pretty crappy example to put on the homepage: 13 lines of Ruby compiled into 67 lines of PHP. You could write some PHP more or less identical to the Ruby in the same original 13 lines.

-----


I imagine the example is pretty indicative of how it works. Better to have a crappy example than no example at all.

-----


Actually most of the code initializes Fructose, in PHP I can write the same code like (6 lines, 7 including blank line):

  class Greeter {
      public static function greet($text) {
          echo $text;
      }
  }

  Greeter::greet("Hello, World!\n");

-----


That code isn't the same as the original. The instance variable is being initialized via a block -- your function needs to accept a callback.

-----


This would be the PHP that'd do the same thing:

    class Greeter {
        public function __construct($fn) {
            $this->greeting = $fn();
        }
        public function greet() {
            echo $this->greeting;
        }
    }
    $greeter = new Greeter(function() {
        return "Hello, World!";
    });
    $greeter->greet();
That code will only work in PHP 5.3. If you want anonymous functions in lower versions, you're going to have to use create_function(). If you want closures, you may as well forget about doing it nicely.

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.

-----


A call of action to all PHP developers out there: We must defend our language against this misrepresentation that PHP is ugly and verbose. It is not a fair comparison of teh power of PHP as it is now. I suggest we start a similar project called "Sucralose" in which we compile PHP into Ruby 1.8 written in Objective-C using MacRuby. I will host it on PEAR. All hail Zend!

-----


Tip of the cap for the fun hack factor. People asking if this is practical are missing the point, I think.

-----


+1

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...

-----


Although I'm sure this was a fun weekend project, which is very cool, I can say that I could actually see something like this being useful IF Ruby could be compiled to PHP which could then be compiled by HipHop to C++.

But still, fun project to see.

-----


How on earth could that be useful? Compiling a piece of Ruby three times down into C, you're going to end up a with an absolute pile of shit.

-----


Sarcasm is lost on this one :)

-----


He's sitting right across the table from me :)

-----


I don't think the OP was sarcastic.

-----


has anyone created the opposite? Compile PHP into Ruby?

(Did I just feel all of the HN rubyists shudder at once?)

-----


Hell, I'm a Pythonista and I shuddered nonetheless.

-----


I've actually played around with this concept. Conceptually it's not very difficult (or at least it wasn't for the code I was working with)... The biggest issue is PHP's reliance on global functions vs Ruby's methods for strings, numbers, arrays, etc. So, for every PHP global string function, for instance, you'd need to pull out one of the arguments and call an equivalent method on it. Bleh.

-----


Is this some sort of snide commentary on how much more limited of a language php is? It doesn't seem like it could possibly be meant for production. I guess I could see it being a fun learning project, tho.

-----


I just sent this out to a friend who was trying to figure out whether to build his simple app in ruby vs. php. Think it made up his mind.

-----


I'm assuming his decision was ruby based on the ugly PHP code in the example? If so, your friend is wrong for two reasons:

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.

-----


That's a pretty stupid reason, though. The two samples of code are no where near identical...

-----


> That's a pretty stupid reason, though.

Yes. So, do you really want him writing PHP?

-----


I don't want him writing Ruby, either. Keep him away from the sharp knives and stupid decisions and give him Java/Play or something.

-----


Is there anything that can do the reverse?

-----


I'm curious - would it be inefficient to use something that could efficiently compile Ruby into PHP such as Fructose, and then use HipHop for PHP from Facebook to compile the PHP into C++? So far I don't see a lot of tools that utilize the Ruby->C++ direction, and much work has gone into HipHop for PHP.

-----


It won't work.

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.

-----


https://github.com/charliesome/Fructose/pull/9

Active community participation too =).

-----


Would be cool if it was self-hosted, written in Ruby, but ran in complied to PHP form.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: