PHP's Enterprise Strengths and Weaknesses, Take 2

CIO — Editor's note: Some readers disagreed with the points made in our previous article, You Used PHP to Write WHAT?! in our series of the pros and cons of each dynamic language. We invited John Coggeshall, senior member of Zend Technologies' Global Services Group, to provide his own enumeration of the dynamic language's suitability for enterprise computing—both its advantages and disadvantages.

Just as a carpenter will tell you that it is much better to use a screwdriver rather than a hammer to secure screws into a wood plank (although arguably both would work), an experienced programmer will say that certain languages are better than others at certain things. So, in the digital toolbox of the developer, where has PHP been designed to work best? And where is it, perhaps, not the best tool for the job?

PHP was designed to solve what I (and others, such as PHP's creator, Rasmus Ledorf) call "The Web Problem," by which we mean the challenges found in the creation of dynamic server-side applications on the Internet or on an intranet. PHP was created to—and continues to evolve to—solve this single problem, which perhaps is the biggest reason why it's been a (if not the) Internet programming language of choice for such a long time. In fact, PHP is the fourth most popular programming language in the world, according to the TIOBE Programming Community Index, above C++, Perl, Python and Ruby. (In all fairness, this probably represents the reality that more people are writing web applications and are turning to a language designed to solve that problem.)

While other languages can surely be used to solve The Web Problem, in this article I explain why PHP is the premier solution for server-side Web scripting.

The Web Problem and PHP

Unlike most programming languages, PHP was designed to function within the challenges of Internet development, which include statelessness, heterogeneousness, typelessness, and the short shelf life of transactions (that is, after all: a typical Web request lasts only a fraction of a second).

For example, PHP is a loosely typed language, which means a variable can switch from one data type to another. This is often a point of criticism for PHP, as developers coming from a traditional background would consider such a behavior sloppy and unpredictable. However, for The Web Problem, such behavior makes sense; after all, the data has no type coming in or going out so why should it have a fixed type in between? The biggest reason might be to add rigidity to the application, but I would argue such rigidity applies only to object oriented programming itself—and to that end PHP does support type hinting for complex types (such as classes, arrays and interfaces).

The Web's stateless nature affects one architecturally significant difference between PHP and other Web languages. Without state, your "Web application" isn't really an application at all. Rather, it's a collection of atomic, individual and completely disparate scripts working in unison to represent a holistic application with no direct way to communicate with each other. To further complicate the matter, multiple copies of a single script can run concurrently for different users; you have to distinguish individuals from each other. (That's where cookies come in, incidentally.)

Plus, each Web request script typically is built, runs and is destroyed within a fraction of a second. Only in a unique set of circumstances would a "traditional" development language be suited for this environment.

Every development language has a different solution to this notion of state. In Java, state is created by maintaining a persistent virtual machine backend. using an application server, to which each front-end Web request must communicate. The application server almost always requires dedicated hardware resources and can be a single point of failure. Plus, it is inefficient to open a second network connection for every incoming network connection, which often then results in a third network connection if the application server business logic must communicate with a database backend.

PHP takes a more simplistic approach because it was designed to live and die within the context of a single Web request. PHP instead relies on standard HTTP technologies, such as GET/POST variables and cookies, to "remind" a given PHP script what its state was (often stored in a database backend, although commercial products such as Zend Platform provide enterprise-ready session clustering alternatives). This architectural simplification has a significant impact on overall application complexity and performance—an impact that could not be achieved in a language originally designed assuming state and a long-running process.

Next: Platform Support and Security

Continue Reading