What’s wrong with PHP
I’ve extracted this text from an internal email I sent some time ago, it sums up my feelings:
….
Now PHP, you might think from this list that we hate it, that’s not true, many of the guys here would probably agree with the points below, but they will also say it works just fine and none of these points are the end of the world - many of them can be avoided with discipline.
Positives
- It’s productive, you can write a lot of code quickly.
- It performs, we haven’t had any performance issues that couldn’t be solved.
- It’s simple, people can usually pick the basics of the language up in a few days.
- For small sites/small code bases on a UNIX platform it does work, we process over 100,000 business messages a day with it and as I said, it works.
Things you should be careful about with large code bases/a lot of applications
We run about 600,000+ lines of code in PHP, in a large environment, the unstructured scripting background of php really comes under pressure. Much of what I say here probably also applies to languages like Perl or the like, but these have been our experiences
PHP upgrades can result in broken scripts/programs
- Upgrading php often changes language features resulting in scripts that crash or error when they used to work.
- For instance, they made it illegal to redefine a function in a class from one version to another, resulting in our whole db layer crashes because it had defined the function ‘get_class’ twice which was no longer permitted. This just doesn’t happen in Java or C
- It can be extremely difficult to maintain structure in the language without either very experienced staff or extremely comprehensive reviews, you can get into bad habits very quickly and your scripts can devolve to crap and become a maintenance nightmare.
- It doesn’t enforce typing, pre-declared variables, class naming or function naming conventions, you will have to invent methods for doing this, we have copied java and the standards used in some large php applications.
It keeps changing its mind
- Ways of working change between version, for instance, how it access web request variables has at least 4 variations resulting in a different way of working for each script.
- Function names in the API are changed between versions, or use inconsistence conventions.
It’s not as portable as it claims
- Scripts that run on Windows may not run on Unix and vice versa
- File IO is a common issue
- Specialist extensions may compile on Linux but not on Solaris or work inconsistently on Windows (we had issues with its xslt handling about 18 months ago)
Finding staff is hard
- You just can’t hire PHP programmers of any quality, they don’t seem to be available where we are.
- We’ve had to train people in PHP, or hire people who are often inexperienced ’script hackers’
It’s not a free as you think
- The leading PHP Development Environment (Zend) is between $250 and $1500 dollars U.S.
- The Zend accelerator (to cache scripts/improve performance) was a couple of grand PER PROCESSOR
- A leading free version of a script accelerator - didn’t work, every 20th page failed to load before we quickly abandoned it.
- There is only one implementation of the langauge - the one by Zend.
It lacks a decent interactive debugger
- The version in Zend Studio 3 and 4was problematic and would often stop working (my personal experience)
- Version 5 doesn’t come close to Eclipse for Java.
The PHP community is often immature
- Few people are writing big and REAL applications in this language (or so it seems)
Long running scripts are unreliable
- On a couple of occasions, we’ve needed to write scripts which process a lot of XML or database activity, we’ve often found they crash after a period of running (like over 10 or 15 minutes), PHP’s memory collection does not seem robust enough for that kind of thing, it would rather be run over and over again than have 1 large program.
Error handling is hard
- Php 5 has exceptions, we don’t use it yet, but we have had trouble making sure our scripts have a coherent mechanism for reporting and logging errors
If you are going PHP then
- Hire programmers with a software engineering background
- They will resist the urge to hack which comes so easily to the self taught/web developer
- Go object oriented
- It helps with keeping structure and enforcing a software engineering attitude
- Maintain separation of responsibility between application layers,
- It enforces structure and maintainability, otherwise people will hack and hack and hack
- E.g., Model - View - Controller or Business/ Data access/ View layer
- Get a good set of third party libraries
- We use ADODb for a our data access layer, but PHP 5 has its own version, use it or something like it.
- Come up with standards for managing script configuration, use of global variables methods of accessing request variables, function names, class usage.
Wednesday, February 1st, 2006 @ 10:28 am
February 1st, 2006 at 4:33 pm
Thanks for articulating these cogent points so clearly. I have only dabbled in PHP but has suspected many of them to be the case before reading your excellent article.
December 18th, 2006 at 12:45 pm
The point is, use the thing that suits you best. At work, when I study, doing private stuff, I’m using all kind of languages and frameworks ranging from JSP to informix datablade to asp.net to PHP. And now I’m trying to digg myself into RubyOnRails. And I enjoy them all. They all have a weak and a strong side. You just have to pick the right thing for the job you are doing. Otherwise we can continue like this discussing forever trying to find the single perfect tool which will never exist!
July 2nd, 2007 at 7:13 pm
You are right.PHP truly has those problem, but one thing missed is PHP can interact well with other platform component like com(dll).
PHP should be concentrated on the web frontend.If there are some heavy business logic,we can also use MQ,ESB,WS or other middleware, also like Reporting and BI,php is not good at,but there are many good java open source project
July 2nd, 2007 at 7:14 pm
sorry,
PHP can’t interact well with other platform component like com(dll).