Thanks to Dave, i read an article over on kuro5hin.org (which, apparently, still does post interesting articles from time to time) discussing PHP5. It’s not in depth, and it really helps if you understand PHP to begin with, but it does present a rather interesting case.
PHP5 isn’t about making PHP more effective, it’s about making it take over the world.
The author does a pretty good job of describing the various object oriented improvements made in PHP and then immediately stating the fact that a great deal of effort was put into something that’s going to be built up and torn down for EVERY SINGLE PAGE REQUEST. (This is something that i have a hard time trying to get folks to understand. Although PHP is a delightful little scripting engine, it does mean that you no longer should think in terms of optimizing for memory so much as optimizing for processing speed.)
The author then brings up a point that i feel like an absolute moron for missing PHP-TNG:EB* added the improved Object Oriented functions so that it can be a proper stand alone language. This makes sense in a weird, semi-twisted, slightly bizarro world view in that machines are getting faster, memory cheaper, virtual machines better balanced, interpreters more optimized, and traditional programming languages more obtuse. And while i don’t think that C/C++ are quite yet the assembly language of the new generation, i’ll agree that they may soon become that.
Thing is, i don’t see the appeal of having Yet Another Scripting Language out there. We’ve already got Perl and Python, both of which do stellar jobs of being hacker-friendly languages, both also on the cusp of major new releases that promise equally magnificent (if also obtuse) feature sets. Now, along comes PHP bargaining for it’s place in the pantheon of the scripting languages.
i can absolutely understand the argument of “Use the same scripting language for web pages as well as the back end”, and it’s pretty darn appealing, until you really think about it from a design point of view.
Building and displaying pages requires callable libraries of functions. Because PHP is fundamentally a scripting language, that means that each script needs to be read into memory, compiled, stored into an object form (since you’re using a compiling optimizer like APC, right?) and then invoked. Sure the optimizer saves some compile time for files that have not been modified, but there are still lots of system calls for stat checks and loads that you’re not going to get around. You can further reduce that load by taking functions and throwing them into libraries. The problem there is making sure that the libraries contain the least number of functions you really need since anything else is wasted memory and processing. What this counter-intuitively means is that sometimes it’s more efficient to put the exact same function into multiple libraries rather than have it located in a single file. Yes, that makes things a bit of a nightmare if you were to try and manage your code with that same function existing in potentially an unlimited number of libraries, but you could easily create a library optimizer function that organizes libraries based on call distribution.
Ok, sing along with me kids: Templates are data. Functions are data too. Optimize your functions like data for rendering processes and no puppies have to die.
Ok, now you see why i don’t get invited to any more campfire sing-alongs.
Let me put this in a slightly different manner. Let’s say you have a very large website that contains hundreds of thousands of pages. You’ve got several choices here, one is be very page friendly and fill your disk with every permutation of every page you’ve got. Another is to create dynamic pages that have simple templates load data from some data repository system.
In effect, what you have is a Model/View/Controller with Scripting Language X being the View/Controller. The Model could (and probably is) something completely different. View and Controller can often overlap since the Controller tends to do things like marshall elements for the view as well as manage connectivity. In an ideal world, View would be separate from Controller allowing for any form of display, but it’s really hard to get folks to do that level of thinking.
In the same way that you probably wouldn’t use rendering calls in your Model classes, why should you require the same language for that? Why not use a different language that has tools better suited for that task? It’s not like this is 1985 and there aren’t hundreds of well documented, standard APIs available.
PHP4 (warts and all) is pretty darn well suited for displaying data on pages. So it doesn’t have exceptions and has weird mechanisms for modifying passed data structures. Who cares? Look, it’s all going away in a few milliseconds when the pages render anyway. If you need/want/desire that sort of persistent long form control over your content there are lots of other alternatives.
i dunno, i could really get on a soapbox here (What? You thought i already was on one? Oh, foolish you.) and maybe i’m just being an old fart for thinking in terms of using a hammer to drive nails and a screwdriver for the screws, but then i’m just funny that way. i guess i’ll just never see the appeal of the Porsche SUV.