About a month back Samuel Levy wrote up a post sharing some of his thoughts on PHP, mostly centered around one idea - that PHP is the right tool for the job (for all the wrong reasons).

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...

On SitePoint today there's a new post from Eran Galperin (of Binpress) about how, if you're jumping immediately to custom software development, you're probably doing it wrong.

Code reuse is largely accepted as "best practice" in our industry. Code reuse has many advantages, such as a smaller code-base which is easier to grok for developers. It's easier to maintain and optimize, since you can make less changes in order to achieve the desired results. Many modern techniques and tools were created in order to better reuse and modularize code. But while we're reusing code, we're duplicating effort. The same code is being written over and over in different places, wasting time and money.

He suggests that custom development should always be a last resort for software development, that there's plenty of other (open source) software out there that meets many of the needs businesses have. In his opinion, component-based development is the future of the industry - pieces that fit together with common interfaces and are larger than the sum of their parts. He sees a "commercial open source" model emerging from the current state of things. This model could result in more well maintained OS projects and more functionality being released as a part of it.

What we have currently is increasing noise, as more and more people have easier access to start programming and publishing their projects. We need to streamline the process and add that missing financial element that makes it sustainable and repeatable.

PHPClasses.org has posted their latest "Lately in PHP" podcast today with mentions of PHP 5.3.8 and some of the wrong ideas that are common when referring to PHP (from their previous post).

Another PHP 5.3 version was released. Manuel Lemos and Ernani Joppert discuss whether you should upgrade to this new version of PHP, as well if you should try the new PHP 5.4 beta version. They also talk about the repercussion of the article about the Wrong PHP Ideas You Should Get Right and why it is important to clarify PHP haters and lovers about these PHP misconceptions.

You can either listen to this latest episode through the in-page player, by downloading the mp3 (25MB) or by subscribing to their feed and getting the latest right in your reader of choice (even iTunes).

On the ProDevTips blog today Henrik describes a situation where he "tried to be clever" with the array_map and array_filter functions and some of the confusion in their usage.

I knew array_filter existed and what it was all about since before, however I started working with something requiring array_map first, all well and OK, array_map looks like this: array_map('callback', Array). So then I assumed I could use array_filter in the same fashion, big mistake.

He was caught by the parameter order difference between the two and problems with how the callbacks worked. In the end, he he spent an hour to create a function to search an array for a partial match and didn't even end up using the array functions (opting for calls to stripos instead).

If you've ever wanted to go to a technology conference (there's several PHP ones out there!) but have talked yourself away from them with excuses, you might want to check this new post from Lorna Mitchell to see if any of them match up. She dispels some of the common misconceptions about attending conferences - five, to be exact.

I can quite appreciate that different people come to conferences for different reasons, but I cannot accept that people actively avoid conferences because they think its not for them - and the reasons for this, from people who have never been to a conference, are wild and varied. Most are based on misconceptions and I'd like to take the time to examine some of these.

She looks at some of the most common:

• I won't know anyone
• It's too expensive
• My employer won't pay
• I might have to talk to people/strangers
• I haven't been to a conference

These along with a few other recommendations can rid you of some of the worries you might have over attending and maybe give you something new to talk to your manager about when the next conference rolls around.

In this new post to his blog Timothy Boronczyk has a few suggestions about what's wrong with the current implementation of object oriented programming in most languages (including PHP).

Proponents of Object Oriented Programming feel the paradigm yields code that is better organized, easier to understand and maintain, and reusable. [...] If objects truly model the way people think of things in the real world, then why do people have a hard time understanding and working in OOP? I suspect the problem might be the focus on objects instead of actions.

He goes on to explain that, in his opinion, the functionality would be more understandable if it focused on the actions from the user's point of view rather than what the object itself can do.

The way some OOP languages (like Java and C#) force objects on the programmer borders on the absurd. [...] Sadly though, that decision isn't left to the programmer who has been tasked with developing and maintaining a system.

In his latest blog post, Aaron Wormus asks the PHP community exactly "what's wrong with PEAR?"

I didn't attend Theo's talk, so the only information that I got was from the blog entries and slides. I realize that this short presentation was humorous, but it still brings up some points that have been nagging at the back of my head for a while now.

The comment in question is part of the Six Reasons PHP Sucks lightning talk.

The comment jokes about the quality of PEAR code. OF course, as Aaron notes, these types of comments aren't anythng new. The real issue at stake is that people don't understand PEAR. To help further the cause behind this (in)famous set of libraries, he's written an article for php|architect to dispell some of the myths.