PHP Question

[Jim Schueler <js...@eloquency.com>]

At least one person in yesterday's discussion wondered if mod_perl might 
be obsolete given the overwhelming dominance of PHP.  I just want to share 
a few observations.

When someone asks me the difference between PHP and Perl.  I usually 
respond that the PHP's core API is bigger by a magnitude of 2.  I 
estimate the core PHP api is around 10K functions.

Fundamentally, the difference is one of entropy, or irreversibility. 
It's trivial to implement the PHP API as a perl module- which with a 
little extra parsing, could even handle the syntax differences. 
Conversely, it seems nearly impossible to map all the perl idioms to PHP 
functions.  A perl standard would accomodate the PHP framework.  PHP 
accomodates nothing else.  I'm pretty sympathetic when PHP evangelists 
discuss the advantages of standardization, but that seems beside the 
point.

The current trend is towards bigger and bigger API's.  Frameworks like 
Joomla and Drupal are falling over each other to push more and more API's 
out to their developers.  There's an obvious advantage to the publishing 
and training support businesses; it might even explain where all this 
momentum originates.  But there's bound to be a backlash.

Almost all the best practices I've learned in the past 20 years are being 
ridiculed as old-fashioned.  I might as well be evangelizing a punch card 
IDE.  I'll be the first to admit that I'm plying my trade in a backwater. 
Here, PHP is the only game in town, and I feel like some old guy crashing 
the party.

Aah!

  -Jim

Re: PHP Question

[Michael Ludwig <mi...@gmx.de>]

Jim Schueler schrieb am 29.02.2012 um 09:04 (-0500):

> When someone asks me the difference between PHP and Perl.  I usually
> respond that the PHP's core API is bigger by a magnitude of 2.  I
> estimate the core PHP api is around 10K functions.

Don't exaggerate. :)

PHP is dull and boring. Not an inspiring language. Still, they got at
least two things right that Perl didn't:

(1) The interpreter could be *safely* and *easily* run in a persistent
(non-CGI) scenario, allowing web hosters to deploy it en masse, hence
making it available to basically everyone.

(I'm not expert enough to tell the difference between PHP as FastCGI
or Apache module without bytecode cache ("accelerator") on one hand,
and mod_perl in "PerlRun" mode on the other, but I would certainly
appreciate an outline of the pros and cons of both modes, or pointers
to such, or even a precise assessment of the differences. I seem to
have a vague recollection of some discussion by people in the know
stating that php.exe maintains less global state than perl.exe and
is therefore safer to host in a multi-client scenario.)

(2) PHP introduced well-known OO syntax into the language, including
keywords "class", "interface", "abstract", "final", "public", private"
and "protected". I do prefer that to Moose because I already know how
it works and how to deal with it. (With Moose, there's just too much
figuring out how you're supposed to be using it. There's too many
features.) So "dull and boring" isn't always bad.

A third thing has, I think, vastly contributed to PHP's success, and
that is its webbiness, coming with $_SESSION out of the box and being
itself a template language. So luring many people in. Wouldn't count
that among the virtues of PHP, but certainly among its advantages in
the webdev marketplace.

-- 
Michael Ludwig