When people complain about PHP being a horrible language, not fit for human consumption, they will often talk about how the features of their favourite language are far more refined; have been designed with elegance in mind; are consistent and secure. And you know what? They're right. But PHP is still a better tool. [...] And it shouldn't be. It really shouldn't. I want another language to knock PHP out of the way. [...] I can't, though, because PHP does one thing really well that no other language seems capable of doing. It works, out of the box, for people who don't know what they're doing.

He goes on to talk about the "installation" required with running PHP scripts and how it makes it mostly "idiot-proof" to use. He points out that PHP has a definite niche in the world of web development languages - one that has a larger need that some others.

This is the challenge for all the people who want to complain about PHP - if your chosen language is so much better (and I have no doubt that in many ways, it objectively is), then make it accessible in the way that PHP is. Until then, keep that double-clawed hammer in your shed in case you want to make... burgers...

PHP is often a misunderstood language by people that either love or hate it. [...] This article attempts to clarify some of the most common wrong ideas that many developers have about PHP. Read the article to the end, so you may eventually start having a better perspective about PHP and take advantage of the opportunities that this language and the PHP ecosystem can provide you.

Among the misconceptions on the list, there's things like:

• PHP cannot do X (access memory, control hardware devices, or some unusual purpose)
• PHP is controlled by only one company (Zend)
• PHP is worse than Ruby On Rails, Python Django, X language Framework
• PHP is not good for high performance scalable Web sites or applications
• PHP developers are cheaper because they are not qualified

The framework that has the best solution for every thinkable problem will simply never exist. Such a framework can't be build for several reasons.

He names two reasons why you should get more specialized in picking which framework you go with on a project:

• First, if a framework wants to provide solutions for as many situations as possible there is less time to focus on the individual solutions.
• Second, it would need to be big and small at the same time.

He notes that, while specializing in one framework can make you more efficient for that task, finding the right framework fit for the project will make you (and whatever team you might be working with) more productive overall.

You'd never dig a drainage ditch with a pitchfork, or plug a drywall hole with chewing gum. Instead, you'd pick an appropriate tool and you'd use it to accomplish the job (a shovel, or some spackle, for example). So why do software engineers often spend so much time fixing problems with the wrong tools at hand?

He includes three common issues and ways you can overcome/stay away from them:

• Lack of knowledge regarding available tools.
• Inability to implement solutions due to lack of resources.
• Unwillingness to implement a solution.

Of the three, the last one is possibly the most scary - don't let personal feelings or your dedication to Tool X be your undoing and hurt your application in the long run.

With the recent talk on the blogosphere about deployment (and for Django, and lots of other posts too), people are thinking about PHP a bit more analytically. I think people mostly get it wrong.

He points out that PHP, in essence, is a CGI-style execution and, in being so, makes it more flexible. Both sides, web and command line, can work with the language equally well. He also mentions the developer/administrator split he sees in PHP's structure and how the language facilitates it.