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\u2014both its advantages and disadvantages.\n\nJust 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?\n\n More on Web Development\n \n You Used That Language to Write What?!\n \n Beyond Ajax: The Future of Web Development\n \n Five Compelling Reasons to use MySQL\n \n Sign up for our Development & Architecture Newsletter\n \nPHP 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\u2014and continues to evolve to\u2014solve 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.)\n\nWhile 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 PHPUnlike 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). \n\nFor 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\u2014and to that end PHP does support type hinting for complex types (such as classes, arrays and interfaces).\n\nThe 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.)\n\nPlus, 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. \n\nEvery 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. \n\nPHP 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\u2014an impact that could not be achieved in a language originally designed assuming state and a long-running process.\nNext: Platform Support and Security\nPHP receives a fair amount of criticism in regard to platform support, especially when you're trying to run it in non-*inx environments such as Windows. Because PHP was originally designed to work in Linux, historically it performed poorly in the vastly different Windows. Some of this was because PHP does not run well in a threaded environment, particularly Microsoft IIS. However, the introduction of FastCGI technology into Microsoft's IIS Web server platform resolves this critical barrier to PHP's success on Windows and has ultimately led to the recent certification of Zend Core (Zend's certified PHP distribution) on the Windows Server 2008 platform. \n\nThink of PHP as a sort of programmable glue. PHP supports 19 databases (including Oracle, MySQL, Microsoft SQL Server, SQLite and PostgreSQL) and all service-oriented-architecture protocols such as SOAP and XML-RPC. You can also work with other programming languages. In particular, there's Com\/.Net integration (free) and Java integration (available commercially although free versions exist) so PHP developers can work with .Net or Java classes.\n\nAdd to that a vast amount of functionality for connecting with LDAP, "Web 2.0" identity management technologies (such as OpenID and information cards), and MVC (model, view, controller) architecture provided by Zend Framework...and you end up with an enterprise language designed with one purpose in mind: creating front-end highly integrated solutions for Web 1.0 and 2.0 applications.Security and PHPPHP has been criticized for not being a particularly secure language, which is simply incorrect. That is not to say PHP hasn't encountered its fair share of security holes on a language level. But as with all enterprise languages, those holes, when identified, are almost always fixed before anyone encounters them being exploited in the wild. Rather then the vulnerability being in PHP itself, very frequently the vulnerability lies in the application that was written in PHP. This is true for all languages. A poorly designed application is likely to result in security holes that can lead to cross-site scripting attacks (XSS), request forgeries (CSRF) or a gamut of other injection attacks.\n\nIf there is a valid criticism of PHP regarding security, I think it's much more balanced to say that PHP has\u2014in the past\u2014made it quite easy for a developer to write insecure code than to say PHP itself was ever incapable of writing a secure application. Thankfully, with the release of PHP 5 two years ago, it is much easier for developers to create applications that don't lend themselves to such attacks as easily, especially when those applications also are built on a well-designed application framework. Next: The Good, The Bad and the UglyThe Good, Bad, and Ugly of PHP Application DevelopmentI think of PHP very much like I think of chess: It's very easy to learn, but incredibly difficult to truly master. This has led to the notion that PHP is useful only in a prototyping capacity: that it's easy to build an application quickly but challenging to build an application quickly and properly.\n\nThat's a fair criticism, and one that projects like Zend Framework have worked very hard to address. The Zend Framework provides an easy-to-use library of functionality that adds the structure that PHP itself does not provide. However, even with something like Zend Framework, there are certain quirks about the language that simply have to be worked with. Notable among them is PHP's amazing lack of any sort of consistency in its APIs. Because PHP was developed in a very organic fashion (especially early on), developers find many curious decisions regarding the API naming conventions. This tends to make a developer's life difficult until he commits the API names to memory (or uses an IDE, which does it for him).\n\nTo further complicate matters, developers cannot rely upon the API consistency from one PHP to the next, even in the same PHP version. This is because PHP's functionality\u2014nearly in its entirety\u2014is derived from a very large group of C-based extensions (which can be enabled or disabled at the whim of the system administrator) and an entire library of other extensions that don't ship with PHP (called PECL extensions), which may not be available at all.\n\nThe result, especially when a developer attempts to write applications to be used by the public at large, is a lot of wasted time and energy. She has to re-implement or otherwise create workarounds for functionality that may or may not be available in the end user's particular PHP installation. Thankfully, if you aren't writing applications that are going to be distributed to the public, this issue can be mitigated relatively easily, simply by standardizing the Web farm on a single version and set of functionality.\n\nPHP has also been very weak in the area of enterprise tooling, especially when compared to other established languages such as Java. Unarguably, PHP can be improved in the spaces of development tooling, deployment and testing. Significant efforts are under way to do so, through projects such as the Eclipse IDE for PHP (Zend provides both a free and a commercial version) and open-source projects such as PHPUnit, which provides an extensive testing and code-coverage suite. The good news is that, while PHP itself is relatively weak in the steps leading up to a production application, substantial tooling is available to monitor and enhance your application if you need visibility into the application's health, using software like Zend Platform (Zend's commercial application server).\n\nIn the past three years, PHP has made significant inroads into making application development faster, stronger and easier. However, use PHP for what it was designed for: writing Web applications. Your best bet still is to use a development framework such as Zend Framework if you plan on maintaining your PHP applications for any significant length of time. Also, plan to spend more time than you may be accustomed to deploying your applications, as while the tools exist to make PHP deployments relatively simplistic and on a par with other languages, the responsibility is yours to piece them together in a way that suits your needs. Happy PHPing!\nJohn Coggeshall is a Senior Member of Zend Technologies' Global Services Group. He provides professional services to clients across North America and sometimes beyond. Coggeshall, who started with PHP in 1997, is the author of three books and more than 100 articles on PHP technologies. He is a active contributor to the PHP core as the author of the tidy extension, and also is a member of the Zend Education Advisory Board and frequent speaker at PHP-related conferences worldwide. His website is a resource for any PHP developer.