PHP does NOT suck, and here’s why
I’m a huge fan of Jeff Atwood and his blog, Coding Horror. He writes in a very approachable manner, using a down-to-earth tone and easy-to-follow examples. He offers useful information to new and experienced coders alike. It’s the one blog I am sure to check on a daily basis. On more than one occasion, Jeff has made an insightful post about a topic that was paramount to a project I was working on. If you’ve never read his work, I can highly recommend the articles on SQL Joins, why upgrades aren’t always a good idea, passing the elevator test, and why the developer’s always at fault.
But the other day, a rare event occurred: Jeff made a claim with which I wholeheartedly disagreed. The post title, PHP Sucks, But It Doesn’t Matter, speaks for itself. Jeff lambastes the language on the whole, while freely admitting to its overwhelming success. The key quote:
I’ve written both VB and PHP code, and in my opinion the comparison is grossly unfair to Visual Basic. Does PHP suck? Of course it sucks. Did you read any of the links in Tim’s blog entry? It’s a galactic supernova of incomprehensibly colossal, mind-bendingly awful suck. If you sit down to program in PHP and have even an ounce of programming talent in your entire body, there’s no possible way to draw any other conclusion. It’s inescapable.
Well then I pulled off a movie-style escape, Jeff. I think the language is a success due to its design, and not in spite of itself. As a professional PHP developer, I think I’m also a bit more qualified than Jeff to comment on the strengths of the language.
Now, almost any discussion revolving around the pros and cons of a coding language can quickly devolve into angry flaming. Jeff of course avoids this pitfall, and I’m going to follow the same spirit of high discourse here. I’ve got two main concerns: there’s some severely flawed logic in the post, and Jeff completely disregards the many strengths of PHP, either deliberately or out of ignorance.
I responded to the logic issues in the comments of the post. Specifically, Jeff uses some fallacious arguments to back up his claim. You’ll have to read the post for yourself in order to grasp what I’m reacting to here (too long to quote). In all fairness to Jeff, I don’t believe he actually intended to make any underhanded arguments. Still, the content of the message is what it is, and ought to be addressed. Here’s the meat of what I said (modified and slightly edited):
By attempting to use facts to make a case for the languages goodness or badness, you commit a naturalistic fallacy. PHP doesn’t suck because it allows you to write function names in three different ways. It does not suck because you consider it ungraceful. It does not suck because crappy coders use it. By the same token, it does not rock because its used by some of the biggest web properties.
Secondly and to a lesser extent, you’ve got a “post hoc ergo propter hoc” (after this, therefore because of this). Just because you used what some consider to be crappy languages in the past, does not validate what you are saying now about PHP. While I can understand and appreciate the effort to “commiserate,” I feel it is expressed under false pretenses.
The claims of suckiness tend to revolve around PHP’s hodgepodge nature; the quotes actually speak to this facet of the language more than the post itself. Summarily, because the language works around other web technologies, it lacks the elegance and cleanliness of some other languages, such as Visual Basic (his example). The effects of a lack of elegance are not discussed, but I estimate that Jeff and the quoted authors would predict some ultimate detriment to the developer or user, most likely in the form of maintainability and the prevention of software rot.
I freely admit that PHP operates as a bit of a mashup, making reading difficult at times. But the problem isn’t with PHP itself, but rather the platform for which it was developed. By its nature, writing for the web is to blend a hodgepodge of technologies. A typical web page these days is equal parts HTML, CSS, and JavaScript, all tied together with PHP. The grassroots nature of the internet compels the development of a language that grows with and as these new technologies emerge and develop. The PHP foundation recognizes this and simply rides the tide.
That being said, I see a larger issue at work here: by valuing internal code elegance over direct markup access, languages like Visual Basic and Ruby on Rails treat browser web output like some kind of necessary evil. These languages tuck the HTML and JavaScript away in built-in libraries, classes and functions, so the developer needn’t ever get their hands dirty. You can write entire websites without even looking at actual web markup.
Am I the only one who feels that this approach does disservice to developers and their users?
My opinion is 180 degrees in the other direction. I really appreciate the fact that PHP works in concert with these technologies, as opposed to superseding them. It allows me to leverage what each technology does best, independently, to achieve my target action in the best way possible. Leaving it up to my server-side code to build the majority of a web page for me sacrifices way more control than I care to give up.
Jeff thinks PHP looks bad and is difficult to maintain. Fair enough. To that, I say web development is a lot like farming: a good website crop yield still requires a guy to get his hands in the HTML dirt a little bit. Always has, always will.
Personally, I think PHP looks pretty damn cool, jumping in and out of HTML. Mix in some dynamically generated JavaScript, or really juice it up by building AJAX from PHP, and you have the makings of some “shit hot” code. I have no trouble reading it, but then again I build on the platform professionally, full-time, and write in an excessively clean fashion. I’m sure Jeff can say the same for VB, as can practically any other professional coder in the language of choice.
Data security without software or hardware
Agree 100%.
I also scratched my head a bit after reading that day’s post from Jeff’s blog (which I also read regularly). Curious to know why he randomly decided to flame a language he admitted to knowing little about. But, you know, whatever.
I don’t disagree with much of what he said either, but I think you’ve made an excellent case for why PHP is so valuable – flexibility.
If I’m a web developer and I have 100 clients hosted in all different shared hosting environments, I can’t depend on every server to have Rails, Perl, or C#. Some will, some won’t.
But just about every shared hosting service nowadays comes with at least PHP 4, so when a client needs an admin tool, CMS, shopping cart, or any other form of server-side scripting, I know I can always fall back the web largest common denominator to work well with whatever web hosting environment I happen to be in.
I would argue that embedding “real” code inside markup is almost always a terrible idea. I cannot immediately think up a case where code with a separate template supporting a simple templating language would NOT be easier to understand and maintain than having both strewn haphazardly within the same file.
Keep in mind that the push these days is also to keep your HTML, CSS, and Javascript separate, for the long-observed obvious reason that mixing bits and pieces together gives you a mess of a file with some four different languages that all serve completely different functions. You can put CSS directly inline in your HTML, too, but for the most part we don’t, and there’s a very good reason for it.
Regardless, you don’t have to use this approach no matter what language you’re using. In Perl you can either print HTML the old-fashioned way or embed PHP-style with Mason. Python’s Mako lets you embed however much Python you need within your templates, but still supports very simple looping, conditionals, and expression substitution. Ruby’s rhtml is just Ruby embedded in HTML; if you really wanted to, I see no reason you couldn’t put your entire app in rhtml. Not that you ever should. But you CAN.
Also, do not compare PHP to Rails. PHP is a language. Rails is an entire framework, built with a certain paradigm in mind and meant to do certain kinds of work for you. Compare CakePHP to Rails, or compare PHP to Ruby. But don’t compare a raw language to a framework and then complain that the framework takes away too much control. You can do CGI-style web programming in plain Ruby just fine. If you really have such problems with frameworks, though, I suspect you either haven’t used them very much or have been trying to fight the one you used instead of working with it. Everything in the RoR MVC family is designed to be as flexible as possible and get out of your way if you really want it to.
Re Aston: I am not aware of a Linux distribution that ships without Perl, and most come with Python. I would also not call a language that drastically changes in functionality based upon the settings in some global file one that works well with *whatever* web hosting environment you happen to be in.
Good points, Eevee. The point in mentioning Rails was simply for example purposes, i.e. clearly defining how some approaches–whether by choice of framework or language–can sometimes make too many assumptions for the developer.
And you’re absolutely right about mixing HTML, CSS, and Javascript, however I think you read my post too closely. I was simply referring to how these technologies work in tandem, and not actually meshing them together in one script. That being said, I’ve found that some more advanced AJAX effects make holding to this rule darn impossible at times.