PHP: the teenage years
For some value of the word “turned,” PHP just turned fifteen. Wow.
I still vaguely remember when I turned fifteen—“rebellious,” “obnoxious” and “bad haircut” are all words that come to mind. But those were also very exciting years, full of hopes, possibilities and the knowledge that, in merely a few years’ time, I would have been able to make the roads a little less safe (in Italy, you have to be eighteen to drive, thankfully).
Milestones are not as important in our industry as they are in our lives—the way I see it, if you work in the computer field and turn to look at back at what has been, someone will have passed you by—but there are some very important lessons that can be learned from the story of PHP.
As a development project, PHP has always been a little rudderless. As a programming language, it is, on the surface, an amorphous and mismatched mass of all sorts of programming paradigms and functions that are sometimes incompatible and in conflict with one another. We have one of the best array libraries in existence—but only because the language constructs that we call arrays are not, technically speaking, arrays at all. It took two major releases to have proper object orientation. And so on, and so forth.
Purists hate PHP because, they claim, it promotes bad programming practices and is, for lack of a more accurate term, a mess. But those of us who have grown to appreciate its strengths know that PHP is like the workbench in your garage: a little messy, but filled with all the tools you may ever need to do any job imaginable. You can’t blame the workbench if you decide to drive a screw into the wall with a hammer.
As it turns fifteen, PHP and its community are like every other teenagers: sometimes lazy, sometimes brilliant, often rebellious and unfocused. The language itself has finally matured to the point where finding new functionality to add is becoming challenging and the real development work has, at least for the moment, shifted to projects that are based on PHP rather than being PHP itself. Frameworks of all complexities and sizes are thriving and occupying an ever-more-important role in our day-to-day development—although those who choose to go “naked” still have all the tools to build their applications without using anything more than what the base language provides.
Going forward, there are some real challenges. The first is going to be preventing the language from stagnating—PHP 6 is languishing to the point where so many people have worked around the issues it solves that it’s going to be difficult to continue working on it in its current state.
The other great challenge is finding a way to deal with the fragmentation that has cemented in the world of PHP frameworks. There is no clear winner in this space—even when you consider “application frameworks” like Drupal and WordPress, there are so many contenders, each with their own large community, that “supporting PHP development” is rapidly becoming a difficult proposition to make. When vendors and users decide to provide solutions for only a subset of the community, we all lose something—even those who gain the immediate benefit, because eventually they will suffer from a weakened and fragmented platform.
Happy fifteen PHP—and many returns.