yep -- there are basically two problems with PHP: the
language sucks, and the implementation sucks. What might
seem a killer third problem -- the standard libraries suck
-- doesn't matter because nobody sensible would write PHP
code to interact with anything more complex than a small
static buffer without a protective layer of code written
in a real programming language -- and if you're wise you
keep the buffer small.
(Another apparently really catastrophic problem -- that
there is no defined PHP language as such, because things
like whether it's default pass-by-reference or
pass-by-value are variable at run-time through
configuration options -- turns out not to be, because
almost all the third-party PHP code in the world is so
abysmal that you're better off without it. So the fact
that it's probably written for a version of PHP which is
configured differently to yours doesn't really matter
because you wouldn't want to touch it.)
I love the idea (proposed in the original article) that
PHP has ``excellent database support''. If only! What it
has are a set of vendor-specific APIs in which the major
design decision appears to have been to maximise the
probability of SQL injection attacks (with which, of
course, real-world PHP code is typically well-supplied).
There is a database abstraction layer, but it is
poorly-documented and hopelessly broken in respect of
important database features like transactions (though note
that in the PHP world ``database'' typically means MySQL,
and so transactions are irrelevant; if you liked your
data, and you wanted to keep it, you wouldn't be using PHP
anyway).
PHP, amusingly, also has no sensible way to generate HTML;
instead, you're expected to do things like,
print ''
. htmlspecialchars($anchor)
. '';
or the equivalent but uglier,
?>=
htmlspecialchars($anchor)
?>
but given that ``Ruby on Rails'' and all those wretched
Python libraries expect the same godawful contortions I
suppose this must be what the market wants. Of course, a
real PHP programmer would write the above as,
?>=$anchor?>
which explains why cross-site-scripting is such a popular
topic of security research.
PHP is also gloriously slow (let's parse the script!
slowly! on every page view! virtual machines are for Java
weenies!) but worrying about that before any of the above
would, I think, be a dangerous case of premature
optimisation.
-- Chris Lightfoot
http://ex-parrot.com/~chris/