Pricking the PHP balloon
Aaron Crane of GBdirect has authored a drop-the-marmalade paper about the use of the PHP scripting language in large web projects. His analysis covers "Separation of Presentation from Business Logic", "Deployment Problems" and "Oversimplification Leading to Excessive Complexity". Here's his conclusion:
"PHP is a convenient language for rapidly prototyping simple dynamic websites. Websites thus built can in many cases be deployed indefinitely, without spending time and money on refactoring code in a different language. PHP's simplicity makes it a good language for inexperienced programmers, such as those moving from a pure page-design r?to a site development one.For more experienced developers, though, the language's simplicity rapidly turns into complexity, slowing down the development process. These developers are the ones who have the skills needed to build large and/or complex websites; using PHP for such sites therefore tends to be a net loss. This tendency is reinforced by PHP's lack of the linguistic features needed to promote working on large software projects. If your project is at all large or complex, it may be better to look elsewhere when choosing an implementation language.
In cases where PHP has been determined to be inappropriate, what language should be used? There is considerable choice here; few languages are as bad as PHP for doing serious development work. The author and his colleagues have had good results with Perl, and believe that languages such as C++, Java, and Python should serve equally well."
Uh, oh, I know quite a few people who will feel unwell after reading this.
Comments
The PHP development work I have done was fairly simple, and in it I could violate the canons of separation of presentation, logic, and data without getting myself into a huge mess. PHP doesn't require that one inline program code in the display code--that's just the common idiom.
One thing I notice is that the article ignores PHP's rudimentary scheme for creating classes, which can ameliorate the namespaces problem.
The limits caused by having a single php.ini file per server are greatly mitigated by the fact that many php.ini directives can also be set in the Apache httpd.conf file.
The article makes good points about conflating hashes and arrays, and about the comparison operators.
PHP is not the best language for projects requiring large teams. Still, I'm not sure the sitation is quite as dire as the article makes it out to be, and I'm not sure just how much better Perl is than PHP in this connection. It does have more language features, but its syntax is uglier and less readable than PHP's, and its object-orientation is much less clean and organic than e.g. Python's. I haven't done Perl web development for a while, but I suspect that separation of presentation and logic would require a templating system, just as PHP would.
Posted by: Chuck Bearden | June 3, 2004 5:22 AM