September 20, 2004
Why PHP still stinks
Yoz just wrote an excellent counter-point to my PHP overtaking Perl doesn't matter post and argues that the Perl community should be bothered about PHP taking away their market share. Yet I'm still not convinced, and here's why.
Let's take a look at what made PHP so wildly popular:
-
Executable PHP scripts in any folder, not just inside your
cgi-binor whatever directory you manually arm for scripting. - The possibility to shuffle PHP code within HTML.
- No modularity, no namespace separation, 3079 functions in the core namespace.
- "No nonsense" procedural-style API with few hints of encapsulation or abstraction of concepts.
Every single point in this list is evidence of a bad design decision, and for any serious developer a valid reason to flush PHP down the toilet and never look back. For the Average Web Grunt, however, priorities are different. He wants to know how to display shit in the browser. He wants to know how to get shit in and out of his database. He wants to get his shit done regardless of the collateral damage involved. And for this purpose PHP's design decisions work like a charm.
The reason for PHP's success? The Average Web Grunt gets away with it. Future-proofing his code is not on the top of his agenda, or that of his clients. He doesn't develop in teams. And for the most part his applications are simple enough that the PHP school of doing development doesn't yet rear its ugly head.
In my previous post about PHP I claimed that "PHP's crudeness is actually by design in order to lower the barrier of entry for people who struggle with other things than programming in their day job.", to which Duncan replied with a trace of cynism:
Yes, I'm sure all the 'amateur' PHP 'kids' are pleased to be writing code in a language whose 'crudeness' is there to benefit them and make sure they get their projects done on time.
So you're going to tell the Average Web Grunt that it's much nicer having to include libraries for any functionality that doesn't belong in the core? You're going to tell him that he's much better off having layers of abstraction between him and his data? That handlers are so 1985 and namespace pollution is a bad thing? That he should learn to work with objects and divide his application into tiers? YEAH, RIGHT.
For thousands of people, PHP is just what they need. Easy to learn, easy to copy & paste and no hard concepts which they must wrap their brains around before they can get shit done. Side effects like awfully designed and unmaintainable applications don't matter for them because due to the the nature of their projects, design, maintainability and complexity are rarely an issue.
Does that mean that other languages are already the holy grail we're looking for? Certainly not. Perl in particular has many grave deficiencies, like the weirdness that Larry Wall calls OOP in Perl, or the difficulty of installing stuff when you're on a $5/month shared server account. What I'm saying is that different user groups have different ideas of what constitutes a good language, and you're not going to take away PHP's pie without doing away with all the best practices that only pay off further down the way.
