Mythbusting PHP: 10 common myths about PHP

PHP development is one of our specialties at Freelock Computing. I've written quite a few PHP applications, some from scratch, some starting with other people's code, some as extensions for open source projects. I've also read a lot of criticism of PHP, and while some of it comes from knowledgeable programmers expert at PHP, most of it is uninformed hogwash. So in this post, I'm going to dispel many of the myths about PHP code, and identify its real strengths and weaknesses. Most myths have a kernel of truth in them somewhere, so I'll try to set the record straight by identifying why PHP has each myth. Ready? Let's get started.

1. PHP is crappy because there are so many crappy PHP programs.
This seems to be the biggest reason people think PHP is a bad language--there are a lot of bad PHP programs out there. Why is this? Probably because PHP is so accessible and ubiquitous that a lot of people without a programming background use it to learn programming. I've worked with programmers inside software companies who have much more formal background, or at least experience programming with others on a team. With somebody to guide them, they quickly learn the pitfalls to avoid, best coding practices, and development methodologies.

Most PHP coders on the other hand started out as web designers, putting together a web page for their neighbor, or their family, or a club of some kind. They have no formal training, no experience working on a development team, no guidance or knowledge about what makes for quality code. The result is inevitably spaghetti code, chunks cut and paste into place without real understanding of how they work, people fiddling with lines until it gives them the result they're looking for.

Naturally, this leads to a lot of crappy software out there, riddled with security holes, maintenance nightmares, poor performance, and many other problems.

That does not mean the language itself is at fault. There are plenty of well-written programs out there that do an excellent job of doing the task they're designed to do.

Result: Busted. Bad programmers does not mean its a bad language.

Let's get a bit more specific about these code quality issues.

2. PHP is crappy because it's hard to read all that HTML mixed in with programming logic.
Some argue that PHP is this way because it is a template language--it was designed to be an easy way to add basic programming functionality to a web site. And while that was its heritage, PHP has grown into a full-fledged powerful language capable of most anything you'd do with any other language.

Nothing in the language dictates that presentation code (HTML, Javascript) needs to intermingle with business logic. I consider the best programs to have a clear division of responsibility between these areas. We use a strong Model-View-Controller (MVC) architecture when creating custom applications, the same architecture provided by many frameworks, and advocated by experts for many other languages. And we're hardly alone in this.

We use the Smarty template system to separate out the templates into a presentation layer. Our model is usually made up of fairly lightweight data objects that own the corresponding database tables. The controller layer is typically a dispatcher of procedural code, often with helper controller objects. You can apply most design patterns to PHP as readily as other object-oriented languages.

Now, the tools you use to develop PHP don't enforce any of this. Unless you're using a framework, you need to create all this structure yourself. But we don't like HTML mixed in with our business logic ourselves, so we don't do it.

Result: Busted.

3. PHP is crappy because it's easy to hijack with all those global variables.
Funny how people try to create all these really easy ways to do things that turn out to be large mistakes from a security point of view. Microsoft has done this over and over. PHP has two particularly annoying "features" that have turned out to be security nightmares, originally there to make it simple to program: register_globals, and magic_quotes_gpc.

register_globals is a setting that takes any parameters passed in a request and automatically turns them into a global variable you can use in your script. The problem with this is that it's very easy for an attacker to pre-define a variable that the script assumes to be unset. As I was learning to program in PHP, I wrote a 500-line script to check and double-check that each variable I was expecting from the browser was legitimate, and that all of my other variables were suitably protected.

At its worst, register_globals turned out to allow an attacker to include a malicious PHP file from a remote web server before your script even started, by setting an autoload variable for a particular module.

register_globals is evil.

But its vulnerabilities are widely known, and PHP has been set with register_globals turned off for several years now. It's going away entirely in PHP 6.

magic_quotes_gpc is more of a pain. It was added to help prevent SQL injection attacks, and what it does is escape all of the values you receive from GET, POST, and COOKIE parameters, adding backslashes in front of any backslash or quote to make it so programmers who pass these variables straight into a database query have some protection built into the language. But it causes a lot of extra work, because your script doesn't know whether this is on or off. If it's on and you escape your strings, you end up with extra slashes in front of everything--and you end up with backslashes scattered all over your pages. We end up checking the setting of magic_quotes_gpc, and if it's on, stripping the slashes before the rest of our script interacts with it.

For any experienced PHP programmer, these are solved problems.

Result: Busted, but there is valid criticism here.

4. PHP code doesn't scale well.
Nonsense. This is purely myth. Here are some of the most popular sites on the Internet that run on PHP: Facebook, Flickr, Wikipedia, Digg, parts of Yahoo. All of those are in the top 20 most visited sites on the Internet.

Result: Busted. Very busted.

5. PHP is mainly a vehicle for Zend to get business.
I didn't hear this one until just recently. Zend is a company with a strong stake in PHP. It controls a lot of the code, it has a decent editor with a debugger, a powerful framework, and a PHP accelerator available as proprietary add-ons. I've had a couple developers suggest that Zend has such a controlling interest in the language that it keeps others out, and you have to buy from Zend to make PHP work best.

Yet this ignores the other options out there. Zend does not have a monopoly in any of these areas. There are several other editors with good PHP debugging support, dozens of frameworks, and a handful of PHP accelerators out there, several of them completely free and open source. Now if you're trying to change the core PHP language, you may need to work with Zend, and I have heard they aren't necessarily the easiest to work with--they don't readily accept changes to core features, and a few developers have left the PHP project because of disagreements over the direction of PHP. And some of these have been serious, related to hardening PHP to prevent some of the preventable security attacks through the language itself.

But as a PHP user, these issues seem far removed. PHP 6 is in development now, promises some decent improvements such as Unicode support and removal of some of the vulnerable settings.

Result: plausible, but not relevant to most PHP developers

6. You can't compile PHP, so it will always be slow.
PHP is an interpreted language, and it doesn't have a built-in compiler. The same is true of other web languages, at least Perl. Python has a built-in runtime compiling system, so you get compiled byte-code without having to do anything. I don't know that much about Ruby in this area.

But you can accelerate PHP quite similar to Python, by adding an accelerator. Zend has a proprietary one. We use eAcclerator on our servers, and there are several others out there. These provide what is called an "opcode cache." When PHP is executed, the interpreter makes two passes: first a conversion to native bytecode, and then execution of the bytecode. An opcode cache stores that first pass to disk, so subsequent calls can use what is essentially the same as compiled code. While it's not permanent, and probably not as efficient as other compiled languages, it does seem to allow our servers to accommodate about 40% more traffic before bogging down.

Combining this with other caching strategies can allow PHP sites to scale up to serve the largest sites.

Result: Plausible, but workarounds available.

7. You can't develop in PHP as fast as other languages. Like Ruby on Rails.
Ok. Now we're getting to the ridiculous one. First off, Rails isn't a language, it's a framework. And by many accounts, it's a good one, providing a lot of really powerful features right out of the box. It might have set a new high standard for developer-friendly frameworks. But it's hardly the only one out there, and because it's open source, many of the conventions it established have spread widely to other frameworks as well. CakePHP is a framework that aims to be the Rails for PHP.

Rails has its downsides as well. The CEO of Dreamhost has an interesting post about his experiences trying to get Rails to scale. While it may be fast to develop in, it may be at the expense of running fast enough to handle large loads. You also need to learn Ruby, which has quite a bit different syntax than PHP. PHP is quite similar to C, Java, Perl, and other popular languages, so it's immediately familiar to many other programmers.

The biggest problem I have with Rails is the dogmatic nature of many of its practitioners. And it has gotten such widespread buzz in such a short period of time that in some ways it's become the new PHP, the new pet technology by a lot of inexperienced programmers due to a low barrier to entry. If you're a web designer and not already a programmer, you would probably choose Rails to get started in today, instead of PHP, because of all the hype. I think that's going to lead to the same proliferation of lousy code that permeates the PHP landscape now.

While Ruby may be a nice language, there's a lot more support for PHP right now, in available talent, web servers, scaling experience, and breadth of libraries available. And by starting with an application that meets 90% of your needs today, you can work on what makes your particular problem unique. Since so many applications and libraries are available for PHP that need very little customization to meet many business problems, developing from scratch with a powerful framework isn't necessarily the fastest way to get the job done.

Result: Busted. While Ruby on Rails is nice, it's not the only way to build an application quickly.

9. PHP is only good for web applications--it's no good for anything else.
PHP was built to be a web application language, but it has a command line interface, a GUI toolkit based on GTK, and other features that mean you can feasibly write just about any kind of application you can think of in PHP.

However, nobody does. I have not seen a single PHP desktop application in use. While we do use it for scripting a few web server-related tasks, they tend to be maintenance tasks or a forked process from a web application. There aren't lightweight PHP libraries optimized to run on embedded devices.

As I look over options to write software for the OpenMoko platform, for example, PHP does not appear to be a compelling option. Likewise, it seriously lacks the ability to interact with hardware or much on the OS level without calling a shell to start some other program. Perl has long been used for these environment, but Python has been taking these environments by storm.

So while it's possible to use PHP for purposes other than web applications, it's not convenient, conventional, easy, or widely done.

Result: Confirmed.

10. It's not a real language--you can't do proper object-oriented designs, objects are copied, etc.
PHP was never designed by computer scientists. You could argue it wasn't designed at all. It was built from the beginning to solve a specific problem: to make active web sites. And it's successful because it's done that exceedingly well.

Over time, it has accumulated modules that do just about anything you might want to do in a web application, from talking to just about any database system out there to requesting pages from other servers to processing financial transactions to generating images and even PDF files. It added object orientation in PHP 4, and made it much more robust and similar to other languages with PHP 5. While it still doesn't do multiple inheritance, or threading, or similar advanced programming techniques, you can implement most common design patterns, objects are now passed by reference, there are constructors and destructors and all sorts of things that give it as much power as any other language for most web applications.

While PHP certainly has its shortcomings, for the vast majority of web applications, it provides exactly the right combination of sufficient power to do the job, and a relatively straightforward way of getting the job done.

Result: Busted, for all but the most specialized applications.

That's enough for now. In a future post, I'll discuss the major drawbacks and benefits of PHP. Stay tuned!