TL;DR Basically it is all Google's fault.
We've seen some pretty epic PHP rants this year, probably the most famous among them are PHP a Fractal of Bad Design, and Jeff Atwood's latest (in what seems to be a biennial broadside) The PHP Singularity.
The common thread in these rants is incredulity that anyone would, in 2012, write new code in PHP. There's a lot of reasons why someone might write greenfield PHP code in 2012. But equally (and this is said as a decade long PHP programmer) I have to admit that plenty of the criticisms levelled at PHP are valid. Yet, for the most part they just don't, particularly, matter.
One criticism that is wholly invalid yet comes up time and time again, is that using PHP intrinsically leads to bad code. I don't feel this is an inherent trait of PHP itself, so much symptomatic of the popularity and low barrier to entry of PHP. Basically there's more examples of bad code out there compared to pretty much any other platform because there's simply more code out there, written by programmers of wildly varying skill. The other problem, is that PHP came into existence as a scratch to a C programmer's itch. PHP was developed at a time where people still actually wrote web applications in C and where the stateless nature of HTTP was relatively respected. PHP, like the web itself, has moved on dramatically since then.
A modern PHP 5.4 webapp looks about as similar to an early 00s PHP 4 webapp as Scala does to Java. Yet many critics when slating the language appear to be code archeologists, excavating pre-historic practices that went out of favour long-ago.
This can be partially forgiven, because owing to the age of the language there's plenty of out of date information out there with high rankings in Google. The ubiquitous w3schools is an unfortunate example of bad practices coming well ahead of sites with more modern approaches to solving problems in PHP.
So 'New PHP' is very different to 'Old PHP'. But the 'Old PHP' is what most people seem to find when searching in Google and this confuses people.
We see this manifested in blogs like Will Rails become the new PHP. This blog has a number of spectacular shortcomings, most egregiously the author's horribly naive view of the PHP community, but the interesting one is his ignorance of the power of Google.
There's plenty of support out there for budding PHP programmers, whether on the web, on forums, or IRC. There are countless, well attended, supported and growing conferences, meetups and the like for PHP programmers. One thing that a community cannot do, is force Google to nuke w3schools' PageRank. Which means that brilliant efforts like PHP The Right Way get swamped by old, incorrect and at times dangerous dreck.
And what the 'Will Rails become the new PHP' author perhaps hasn't realised, is Rails, at least in the terms he's trying to couch it, has already become the 'New PHP'. I am a novice Rails developer, I like to hack around in it as it can be quite fun to spike out solutions. What I've been struck by, is the sheer amount of bad advice out there. Advice novices will come across, if they turn to Google for help.
If you're well versed in a platform you learn through brutal experience what works, what doesn't and your nose is finely tuned to bullshit. When I read a PHP article I know instinctively if what I am reading is reliable. But with Rails, as a novice, I don't quite have that sense, beyond my own background experience with other programming languages.
So let's look at an example. I've been working on a dead simple Rails authentication webservice. It listens for HTTP requests for /login, /logout, /session, etc., and emits either XML or JSON in response. I'm using the respond_to method to serve out these responses. Unfortunately what I found is if I request a route that does not exist, I get an HTML error back. This doesn't make a lot of sense for a webservice that otherwise speaks XML and JSON.
Other global exceptions similarly respond with HTML. I don't want to wrap every action up in a begin/rescue block and there is certainly no way to intercept router exceptions in actions anyway. So I needed to learn how to catch global exceptions.
In my journey of (Google) discovery I came across this blog post and appeared to hit paydirt. The advice appears to be legit, hell someone in the rails community even featured it in a podcast. So on the face of it this seems good. But that switch statement sure is smelly. Does it, really, need to be this hard?
Now my general purpose programming brain recognised that this code while solving my problem, is not ideal. And why is it not ideal? This one method sure has a lot of responsibility. Method names with plurals in them are usually a code smell. Over time as more specific exceptions need to be handled I would end up with code that is as easy to read as Goethe's Faust, photocopied and in the original Gothic script (not easy). What we have here is a God Method in training.
Now, what if I am a Ruby/Rails/Programming novice? I have got plenty of other stuff to learn, I'm going to go right here and Cargo Cult this code into my webapp and move on. Just like all the rookie PHP coders do, right?
Well, I didn't do that. I saw that this rescue_from method was pretty awesome and so I went to the Rails API docs to look it up.
API docs for any language are pretty terse, but what jumped out at me was this line:
“Handlers are inherited. They are searched from right to left, from bottom to top, and up the hierarchy. The handler of the first class for which exception.is_a?(klass) holds true is the one invoked, if any.”
This isn't great documentation admittedly, but it means basically, if you put rescue_from Exception at the bottom of the list of rescue_from handlers in your application_controller.rb file, then since everything derives from Exception, nothing else will get a look in (Rails will look at the handlers from the bottom up).The author of that helpful blog we found didn't realise this, and so his solution was needlessly complicated.
What can we learn from this? Well Rails programmers certainly live in a glass house and shouldn't throw stones is one thing. But on a slightly less trollish note, there is a problem here for all novice programmers that turn to Google to help them solve problems. The answers on Google are usually either wrong, or at best, incomplete. As the web gets older, bad and out of date advice piles up making it much harder for novices to find good advice.
Knocking a language for this phenomenon (or a framework, seriously, whatever) is more than a little ignorant and doesn't solve the problem. Efforts like PHP The Right Way is how PHP is trying to fix it. If Rails really doesn't want to be the 'Old PHP', they need to realise it's less to do with languages and platforms, and more about SEO.