The Right Retool for the Job

Facebook’s publication of the HipHop transformer and runtime raised the question of whether PHP is really the right language for a web site that has scaled to massive volumes.   The same was asked of Twitter when parts of its Ruby code were rewritten in Scala.

Of course it is.

Proper language choice is based on “the best tool for the job.”  In the case of Facebook, Twitter, and many others like it, “the job” was to get a web site up fast and very quickly evolve it.  Without PHP, Facebook probably wouldn’t have been created.  Productivity, web-orientation, innovation, and even fun trumped raw performance, so PHP and Ruby won the day for those two sites.  No-one would code a web site in C++, just as no-one would code a real-time system in PHP.

If productivity and agility are your primary concerns, pick a language and platform that makes it fast and fun.  I recommend a dynamic, object-oriented language.  If it’s a web app, consider Seaside.  If productivity isn’t important but commodity skill sets and ubiquity are your primary concerns, you might choose Java: the COBOL of the 21st century.  Just don’t be a lemming, letting TPCI ranking become a deciding factor.

And don’t make the decision based on hearsay and perceptions of performance.  Today’s performance tuning and scaling tools (profilers, monitors, load balancers, and even static analyzers) make easy to identify the true bottlenecks and fix those, leaving the non-time-critical majority of the system as is.  Speculative performance tuning can be counter-productive, so if it ain’t broke, don’t fix it.

HipHop is a welcome addition to the PHP universe: the ease and productivity of PHP with the speed of C++.  Hopefully it will mean that PHP developers no longer have the specter of scalability issues hanging over them.  Now, if we could just get some overdue cleanup and deprecation (eliminating redundancy in favor of cleaner object-oriented design), life would be grand.  But that’s another story.

I’d like to try out HipHop, but frankly, I don’t need to.  With the possible exception of a CiviCRM site that I pushed to the limit, my PHP sites just don’t need additional horsepower, and I certainly don’t have to worry about reducing CPU utilization on a few thousand servers.  Obscurity isn’t always a bad thing.

Share This:
  • Print
  • Digg
  • StumbleUpon
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Google Buzz
  • RSS