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, ?> http://ex-parrot.com/~chris/