Pinderkent

Although widely used, PHP is known to have many, many problems. Security-related issues have always been problematic for it. Performance is another area where there have been numerous problems. In many cases, its semantics and syntax leave much to be desired. Some people believe that a rewrite of the PHP implementation itself will solve all of the problems associated with PHP. Others lean towards that viewpoint, but suggest that the current PHP developers should not be involved with such a rewrite. Personally, I think PHP as a language is inherently flawed, and any implementation that tries to remain true to the "spirit" of PHP will itself be flawed.

Security, for instance, has always been a problem for PHP. Part of this problem is independent of the implementation. PHP, as a language and platform, has always proved attractive to inexperienced developers. To a large extent, PHP has even been marketed towards amateurs and hobbyists. Such people are not aware of the various SQL-related exploits that are possible, let alone how to prevent them. So when their PHP-based Web sites went public and were subsequently cracked, the PHP developers ended up adding half-brained "solutions" like the notorious magic quotes. So we can see at least two problems here. The first is that PHP is targeted towards and widely used by people who don't understand security. The second problem is that the developers of PHP tried to compensate for this in ways that just caused further problems.

The developers of PHP have made a good decision by opting not to include magic quotes in PHP 6. But there's nothing they can do about their language being widely used by people who probably shouldn't be using it. The insufficient experience and knowledge of its userbase would be a problem for every PHP implementation.

Likewise, performance has always been one of PHP's biggest problems. A variety of approaches have arisen over time to deal with these issues. Caching the compiled PHP code is one of the most frequently-used solutions. Any implementation that wanted to improve on PHP's performance while allowing for source deployments would likely need to incorporate such transparent caching, which in turn may not be flexible enough for many users. Other approaches would include forcing the user to deploy some form of pre-compiled object file, rather than deploying the source code itself. But this is contrary to how PHP has historically approached deployments.

The lack of organization is one problem that the PHP developers have begun to tackle with the introduction of namespaces. But even the selection of a namespace separator has been highly controversial within the PHP community. This incident indicates the struggles and hurdles that any other significant reform efforts would face.

Arguably, the only way to successfully reimplement PHP is to discard the language as it exists now, as well as discard the community that it has now. Discarding the community will be problematic, as it is the armies of inexperienced users who make PHP as popular as it is. Many of the language changes would in turn make the resulting language much unlike PHP, as its users currently know it.

Today I was forwarded a link to an article suggesting that PHP became popular "because of its merits". Furthermore, the article goes on to suggest that PHP became widely used because of its "features" and "power". I'm not so sure that's actually the case.

I think PHP's popularity arose from it having few barriers to entry, and because there were few viable alternatives. But before we can consider this, we have to look back to when PHP started to become popular. This would have been during the late 1990s and early 2000s. At that point in time, commercial Web hosting providers had limited options for hosting a large number of Web sites on low-cost Web servers. Unlike today, VMware's offerings were in their infancy. Alternatives like Xen and OpenVZ weren't yet around. So VPS-like offerings were very rare, especially at a price that a student or hobbyist could afford.

Most users of affordable shared hosting weren't able to have much control over their servers. The hosting company would often not give any sort of shell access, but rather just use Linux and Apache vhosts, and allow their users to upload their files via FTP or a Web interface. Some of the better hosts allowed for users to deploy CGI scripts. In practice, there were often severe limitations, however. The choice of language for these CGI scripts was typically between shell scripts or Perl scripts.

So to develop an interactive Web site, many people ended up learning Perl, as it was their only viable option. Perl is a powerful language, but it does have a higher barrier of entry than PHP, especially in terms of its syntax. People unwilling or unable to work with Perl had to choose an alternative. In most cases, this ended up being PHP. Ruby on Rails did not yet exist. ASP was basically limited to servers running Windows, which many shared hosting providers did not use. Java-based Web solutions were too resource-intensive for what shared hosting providers could offer each user.

PHP was free, open source, ran on Linux, and could integrate well with Apache. Thus when users specifically requested it, many shared hosting providers were willing to install it. For many users, it proved to be an easier and more enjoyable language to use than Perl. Many hobbyists, and especially students, became familiar with it. They'd develop interactive Web sites that they could then affordably host with one of the numerous shared hosting providers who did support PHP. Soon enough, some of these sites were converted to more general PHP apps, some released commercially and many released as open source software.

At this point, we not only had developers using PHP, but non-developers who still wanted to have a Web site started using pre-developed software written in PHP, as well. This is when its popularity really started to take off. But we need to keep in mind that it wasn't because PHP was technically superior or even comparable to Perl, or the other available Web-oriented languages. In many ways it wasn't, and usually still isn't.

It was essentially the only option, besides Perl, available to those who wanted to put up an interactive Web site with minimal cost and effort. Even if you didn't want to use PHP, if Perl's offerings weren't suitable or not usable with your host, you fell back on PHP. A side effect of this is that many younger developers took the language from the student/amateur/hobbyist world to the professional software development world as they progressed in their careers. We started to see larger and more popular sites be implemented using PHP, even when other languages and platforms were available.

When considering it from a technical perspective, it's clear that PHP is often very lacking. The language itself isn't remarkable in any way. Compared to many other programming languages, the language itself it is immature and sloppy. It offers a large library, but it is a inconsistent mess relative to what Perl, Python, Ruby and Java offer. Security-wise, PHP has long been known as pathetic. Looking at the changelog for PHP 5, we see a huge number of security-related fixes, even as late as the 5.2.7 release, which came nearly two years after 5.2.0, and over five years after 5.0.0 Beta 1. In terms of performance, PHP has never been known as a winner, often indicated by the necessity of a PHP accelerator for even low-traffic sites. Finally, in terms of maintainability, PHP code is often a terrible mess, often because it was written extremely quickly and with little care.

We can't deny that PHP is popular. It obviously is very widely used, by big and small players alike. But this popularity arose not because of technical merit, but rather because it was the only option available at the time, leaving people with little or no other choice in the matter. Times have changed. That's why alternative programming languages and Web frameworks have become widely used. People realize that they now have options, and thus make use of them. I know many Web developers who are extremely happy to be able to move away from PHP. If PHP truly did offer significant technical benefits, we wouldn't see the eagerness we currently see towards Ruby- and Python-based Web solutions, as PHP would be more than sufficient for most.

Like many technologies, PHP's rise to fame was more accidental than earned by merit. It was in the right place at the right time. And so we shouldn't consider it bad to criticize PHP when such criticism is due. It has served many people well, but that still doesn't mean that it isn't lacking in many, many, many respects.

Several months back, there was somewhat of an uproar in the Ruby and Ruby on Rails communities when it was revealed that after two years of effort, the CD Baby Web site was abandoning their Ruby on Rails rewrite. The CD Baby site was reimplemented in mere months after returning to the use of PHP. This past week, I have been working with another company that is in a very similar situation.

In this company's case, they had a number of legacy, in-house systems developed in C and COBOL that were eventually moved to Web applications written in Java in the late 1990s. By early 2006, their Java-based software systems were starting to show their age, and it was decided that they would start rewriting many of them using Ruby on Rails. After an initial analysis and design period, the implementation began, with the greatest portion of the work being completed by August of 2007. The rollout was complete by the beginning of last September.

There has been an endless stream of complaints from the users of the software since that time. I've read through six 3" binders full of complaint reports. Now, the software itself isn't poorly implemented. It's actually among some of the better corporate Ruby on Rails code that I've seen over the past few years. Design-wise, it's actually pretty decent, too. From the complaint reports I've read, most of the users are also happy with the performance of the system. It's just that the applications themselves cannot be used well in a productive manner.

After talking to a number of the developers who were involved with that project, I heard repeatedly that Ruby on Rails was too restrictive in a variety of ways. The developers had to developer towards what Ruby on Rails would effectively let them develop, rather than developing the software to meet the needs of the users. The management had decided on a Ruby on Rails-or-nothing approach, so using alternative technologies in such situations was unfortunately not an option.

At this point, the company is trying to return to their Java-based systems, which worked better than their Ruby on Rails implementation. This will not be an easy task for us. Their data model changed in many ways, to name one major stumbling block. It's not been decided yet whether they'll update their Java code to handle the new model, or transition their new data back to the previous databases. Regardless, that aspect of the transition alone will be difficult. Updates to the Java code to handle the new capabilities introduced to the Ruby on Rails system since its deployment will also be required. There has been some consideration of a hybrid approach, with some of each system being used, but some of the stakeholders feel this will only cause more problems.

A lesson we can take from this, beyond the obvious ones, is that when performing a large-scale rollout of a new system, it's important to be able to revert back to the existing system nearly immediately. Not only that, but it should be possible to do this several months after the new system is initially rolled out. Although it will incur an extra cost of doing business to maintain the old, albeit unused, software for some time, not having it available to roll back to could be tremendously more costly.

A few days back a colleague forwarded me a link to an article entitled Attacking PHP. It goes through a list of the problems associated with PHP. And based on my past experiences dealing with PHP in corporate environments, the analysis in that article is spot on.

In short, PHP is just not a suitable language for serious Web application development. I've seen it used for a wide variety of Web apps at numerous companies, but the results have always been negative.

As the article mentions, one of the main problems with PHP is that it's sloppy. The standard library naming scheme is one particularly problematic area. This in turn promotes sloppinesss elsewhere, namely for those developers who use PHP to developer their own applications. Try as a developer might to keep his or her code clean, the use of standard PHP functions will begin to introduce inconsistencies.

The mixing of content and presentation is of course another very sore point when using PHP. Although it is possible to avoid this, we don't always see this in reality. It becomes very convenient in the short term to mix those two distinct layers. But once an application starts to mature, nothing but problems arise. For instance, one team I worked with would continually break the logic of their PHP Web application when making cosmetic changes, since the business logic was so intertwined with the presentation code.

And when dealing with the Web, security is paramount. The Web is a very hostile place, and so we need to use programming languages that help enforce good software design. In this respect, PHP's dynamic nature is unacceptable. While it allows programmers to rapidly create Web applications, these applications are often full of security glitches. Furthermore, type-related errors all too often cause problems when using a PHP application. Users are not impressed when an application crashes due to a failed type conversion because the PHP developer wrote sloppy code.

When you combine the factors above, you end up with a language that also promotes the development of near-unmaintainable code. Even if a PHP application is initially developed by somebody with patience and discipline, this level of care must be maintained throughout the entire lifetime of the PHP application. If the development standards drop for even the slightest of code, it is quite likely the PHP application will become a mess quite soon. Although languages like Java and C++ are not immune to such problems, they do tend to be far more resilient than PHP.

In short, PHP is just not a language that should be used for most large-scale applications. Although it may have its place for small Web sites, bringing it beyond that is just looking for trouble and heartache. Basically every time I have seen PHP used for real software development, the result has been spectacularly horrid.

Michi Kono recently wrote about how the most talented Web developers are usually also the most talented application developers. I propose that we take it a step further: a great Web developer is usually a superb application developer. Or in a different light, a great Web developer is a waste of a really great application developer.

Fairly early on in the article, Michi makes this statement: Nothing is inherently easier about developing an application in PHP than in C++. That is quite true, but I don't think it goes far enough. What we usually find is that developing a Web application in PHP is more difficult than developing a comparable desktop application in a language like C++, Java or C#. When using a language like Python for GUI desktop applications, the inefficiency of PHP (and Web development in general) becomes quite apparent.

Large-scale Web development is usually not a pleasant experience. One of the main problems is just coping effectively with the wide variety of technologies that are involved in Web applications. Not only is knowledge of HTML required, but so is knowledge of JavaScript and CSS. And that's just for the front-end. You still likely need to know PHP, Java, Ruby, or some other language when developing the back-end of the site. As most applications require some sort of database access, you usually have to add SQL into the mix.

Granted, the essentials of those languages and technologies are not overly difficult, and are well-understood by most developers. But it's still not a very effective way of developing software. Some may argue that we see multiple domain-specific languages in use, and that may be the case. But the end result is that we often have developers who are over-streched when it comes to implementing advanced features. There is only so much knowledge that a typical developer can effectively acquire and manage, especially when deadlines are looming.

Five years ago, many of us were developing enterprise applications using C++ and the MFC, or Java and AWT or Swing. Since we were really only using C++ or Java in many cases, we were able to become quite familiar with all aspects of those languages. We didn't have to learn two or three separate languages for developing the UIs of our applications, as they were built upon the common constructs of C++ or Java (usually with the help of a GUI designer utility).

Languages like Java and C++ allow for large, complex applications to be developed with relative ease. They have a rich heritage. They were initially developed, and subsequently evolved, by those who had to deal with massive software systems. The Web technologies, on the other hand, grew from the low-end up. And it shows. They lack the coherency of languages like Java, C++, Smalltalk and Python.

CSS, HTML and JavaScript also lack what I'd like to label as "maturity". This isn't maturity as in their age, but as in the raw experience and knowledge that went into designing them. It just isn't there, or at least doesn't come from the world of large-scale application development.

One area in which Web application development is particularly pathetic is when it comes to debugging. There are a wide variety of excellent debugging and program tracing tools available for languages like C++ and Java. It's only recently that we've been seeing Web development tools like Venkman become somewhat suitable.

So in my past experience, I've generally seen excellent application developers suffer from a significant decrease in productivity when dealing with Web development. Many times this has been when it comes to debugging large Web applications. The disjointed nature of the various Web development technologies proves to be a significant hindrance, especially when compared to the more cohesive technologies like C++, Java, Smalltalk and Python. Were those developers instead developing using technologies like those, they'd be far more productive, and the resulting applications would be far more portable, efficient, reliable and enjoyable to use.