A roundhouse kick, or the state of PHP
Last week the usual round of PEAR-bashing on Twitter took place, then this morning Marco Tabini asked if PHP (core) was running out of scratches to itch. He also suggests he got this idea from Cal Evan's blog post about Drupal forking PHP.
[Not submitting to your linkbait.]
Pecl and PHP
So first off - moving libraries from the core to an external repository was done for various reasons. One of them is to not have to maintain more and more in the core - keep it small and lean. Though small is pretty relative in this respect.
Of course doing so, means that people who do not have root on a server cannot install the module in most cases. But I'm inclined to suggest that when a pecl extension is (really) required, there should be nothing holding you back.
And if there is no way, thanks to PHP's extentability there's almost always a PHP-equivalent to any c-extension available.
Drupal and PHP
I know a couple Drupal people myself and most of them consider themselves to be Drupal developers before PHP. Why is that? It's because Drupal found a great way to abstract whatever people annoys about PHP from its developers, thus enabling them to build websites.
Is this a good or bad thing?
Of course it's a good thing because it makes people productive.
It's also a bad thing, because it seems that some (Drupal) people are rather disconnected from upstream [PHP].
Whatever people think about Drupal or any other framework, keep in mind that apparently it's PHP (and not Ruby, Python or pure C) which is more than a good enough enabler because PHP allows people to build a sophisticated content-management-framework like Drupal on top of it.
Drupal is of course no exception here. Despite e.g. the standstill in Ruby-land, in PHP other tools developer over the years who are a defacto standard: take a look at Wordpress or phpBB.
If you'd like to take it down to the framework-level there are projects like Symfony, CodeIgniter, Zend Framework, ezComponents/Zeta and also PEAR.
Fork vs. wat?
I think that forking PHP is a joke and I believe that Cal doesn't know the difference between a fork and a custom package (or a distribution).
A fork usually adds or removes features from the actual code base, but reading Cal's blog post he suggests a custom package. [Woo! Technical details! They get lost along the way!]
The thing is that a lot of people do this already. The people maintain a PHP package for a certain Linux or Unix distribution - Debian/Ubuntu, Gentoo or FreeBSD - there are doing it already. Using these as an example, whatever OS is used, it already runs a customized version PHP; some distributions customize more than others.
No one objects to the Drupal community suggesting ./configure flags or maintaining packages for the various flavours of Linux and Unix, or even Windows.
I would even go as far and say that in order to optimize the stack completely, it wouldn't hurt Drupal if its community recommended flags and extensions for people who run Drupal sites.
I doubt though that anyone will maintain packages for a couple distributions in their spare time and that the majority will not benefit from this effort because they don't run Drupal on their own server. But generally this optimization is enterprisey enough and indeed what I call a business opportunity.
Moving Drupal to ...
So what's "..."? Moving it to Python or Ruby, or maybe Scala? Good luck with that.
While the majority of Drupal developers don't consider themselves to be PHP developers, they still live and benefit off the PHP ecosystem. Think libraries used in modules or used for other areas like testing. Good luck porting those.
Then add PHP's vast adoption among webhosts.
Last but not least
Which brings me to the in my opinion biggest selling point: Doing PHP has another slight advantage over Ruby, Python and the other languages - it's installed on over 90% of the shared webhosts out there.
I invite everyone to google php hosting< Truncated by Planet PHP, read more at the original (another 5869 bytes)
Truncated by Planet PHP, read more at the original (another 5869 bytes)