4 ms·

I wonder if it'll let you convert things out of the box or if it was optimized for the way php is written at facebook. (eg. it doesn't support eval() but eval()

by aditya 17y ago

I wonder if it'll let you convert things out of the box or if it was optimized for the way php is written at facebook. (eg. it doesn't support eval() but eval() is bad anyway) Also, how hard would it be to do the same thing for Ruby and Perl? I'm sure there have been other attempts at compilers, but as noted elsewhere, having FB behind it makes HipHop more stable... Oh, and atleast one thing from this anonymous interview came true: http://therumpus.net/2010/01/conversations-about-the-internet-5-anonymous-facebook-employee/?full=yes http://therumpus.net/2010/01/conversations-about-the-interne...

daeken 17y ago
I wrote a PHP->C++ compiler and bits and pieces of the standard library many moons ago (BinaryPHP: http://sourceforge.net/projects/binaryphp/ http://sourceforge.net/projects/binaryphp/ ), and it really wasn't terribly difficult, even for a complete compiler novice. We didn't do the fancy optimization that HipHop does, but it worked fairly well at the time. The actual compiler would probably only take a month or two (disregarding real optimizations) for a talented developer or two, but the runtime (assuming it doesn't share anything with PHP proper -- don't know if this does or not) would take much, much longer. Doing it for Ruby or Python would be fairly straightforward to get running initially, but doing Perl<=5 would be impossible (for all cases) due to it being proven impossible to statically parse.
- viraptor 17y ago
  You can compile any code - full static parsing doesn't have anything to do with that. If you have a place that is not possible to parse one way, you do a switch on the condition that causes the parsing choice. Then you compile each branch assuming that code was parsed in a specific way.
raganwald 17y ago
how hard would it be to do the same thing for Ruby... ? Much harder, but not impossible. The two issues are (a) how much of Ruby the language can be compiled to C++ using Type Inference, and (b) For the stuff that can't be compiled, how often does it show up in production code? FB's PHP solution relies on having a large code base with few instances of code that doesn't compile cleanly. With Ruby, I suspect both issues are a problem. I think there's a lot more of Ruby the language that will be difficult to infer, and furthermore I think Ruby programmers tend to use those features a lot. That's just a guess, mind you. You could probably do a lot if you make some major breaks with tradition. For example, if instead of compiling Ruby source code you load Ruby classes, run all the meta-programming, then reverse-engineer the source (ParseTree can do this with Ruby 1.8 but not Ruby 1.9), you could basically do the meta-programming in interpreted mode but run the resulting code in compiled mode. I suspect that would work well for a lot of Rails programs where the hairiest stuff is run when classes are loaded, not on the fly when responses are being served.
- rufugee 17y ago
  Wouldn't the challenge in ruby be the prevalence of things you just can't and don't do in PHP? Thinks like instance_eval, class_eval, etc....in Ruby projects I've worked on (and especially in Rails), these are all over the place. Of course, assuming these calls all happen on the front end (source load) and not downstream in response to some triggering event, your approach would probably work.
  - raganwald 17y ago
    `instance_eval` and `class_eval` are very hairy if you pass strings (which you MUST do for some kinds of template metaprogramming). But they aren't hairy at all if you pass blocks, where all you are doing is (essentially) setting `this`.

by aditya 17y ago

daeken 17y ago

I wrote a PHP->C++ compiler and bits and pieces of the standard library many moons ago (BinaryPHP: http://sourceforge.net/projects/binaryphp/ http://sourceforge.net/projects/binaryphp/ ), and it really wasn't terribly difficult, even for a complete compiler novice. We didn't do the fancy optimization that HipHop does, but it worked fairly well at the time. The actual compiler would probably only take a month or two (disregarding real optimizations) for a talented developer or two, but the runtime (assuming it doesn't share anything with PHP proper -- don't know if this does or not) would take much, much longer. Doing it for Ruby or Python would be fairly straightforward to get running initially, but doing Perl<=5 would be impossible (for all cases) due to it being proven impossible to statically parse.

viraptor 17y ago
You can compile any code - full static parsing doesn't have anything to do with that. If you have a place that is not possible to parse one way, you do a switch on the condition that causes the parsing choice. Then you compile each branch assuming that code was parsed in a specific way.

raganwald 17y ago

how hard would it be to do the same thing for Ruby... ? Much harder, but not impossible. The two issues are (a) how much of Ruby the language can be compiled to C++ using Type Inference, and (b) For the stuff that can't be compiled, how often does it show up in production code? FB's PHP solution relies on having a large code base with few instances of code that doesn't compile cleanly. With Ruby, I suspect both issues are a problem. I think there's a lot more of Ruby the language that will be difficult to infer, and furthermore I think Ruby programmers tend to use those features a lot. That's just a guess, mind you. You could probably do a lot if you make some major breaks with tradition. For example, if instead of compiling Ruby source code you load Ruby classes, run all the meta-programming, then reverse-engineer the source (ParseTree can do this with Ruby 1.8 but not Ruby 1.9), you could basically do the meta-programming in interpreted mode but run the resulting code in compiled mode. I suspect that would work well for a lot of Rails programs where the hairiest stuff is run when classes are loaded, not on the fly when responses are being served.

rufugee 17y ago
Wouldn't the challenge in ruby be the prevalence of things you just can't and don't do in PHP? Thinks like instance_eval, class_eval, etc....in Ruby projects I've worked on (and especially in Rails), these are all over the place. Of course, assuming these calls all happen on the front end (source load) and not downstream in response to some triggering event, your approach would probably work.
- raganwald 17y ago
  `instance_eval` and `class_eval` are very hairy if you pass strings (which you MUST do for some kinds of template metaprogramming). But they aren't hairy at all if you pass blocks, where all you are doing is (essentially) setting `this`.