Florin Patan has posted about what he calls the next big thing in PHP - his observations of the current state of the language/community and what could be coming down the road.

What's the next big thing in PHP? Or more accurately, how do you get to wish/want for a next big thing in PHP? PHP currently is seen as a jack of all trades, master none by most of people outside of PHP world and it's starting to look the same way for people who are using it as well. How did we got there?

He spends a lot of the post talking about the future of PHP, though - what could be coming along with a PHP 6 release. He suggests that, with the way things are going, PHP could not be around too much longer if something dosen't change. He also makes several suggestions to the core PHP developers about what they could do to help the situation including strong typed variables, a "smarter parser" and a poll for PHP.net asking the users what they want in the language.

This should be the next big thing in PHP. Collaboration and better community interface for both worlds, users and devs. Help us help you on PHP6, help us making a better world for everyone using PHP.

In his latest post, Jason Lefkowitz takes on something that's praised by PHP developers and non-PHP developers alike - the documentation for the project. There's just something he finds messy about the whole business.

Really, it has more to do with the way that PHP's structured than the actual documentation. It's just a case of art imitating life.

Now, having lots of libraries isn't necessarily bad — Java has an even more Herculean list. It only becomes a problem when you make no distinctions between them in the docs — like PHP.

PHP just throws a huge list of libraries at you and leaves you to figure out which one you need. There’s no overarching "Database" package — instead you get Postgres functions and Oracle functions and Firebird functions and MySQL functions, all sprinkled throughout the list.

He also comments that the entire listing is also cluttered with other functionality, things that most developers would toss aside if they came across - they just don't need them.

His point isn't without merit - there is definitely a need to reorganize things in the manual to make them a bit more "topic friendly". The documentation is already one of the most well-maintained in the Open Source community, so the content is there, maybe it's just the structure that needs to be changed.

In his latest post, Jason Lefkowitz takes on something that's praised by PHP developers and non-PHP developers alike - the documentation for the project. There's just something he finds messy about the whole business.

Really, it has more to do with the way that PHP's structured than the actual documentation. It's just a case of art imitating life.

Now, having lots of libraries isn't necessarily bad — Java has an even more Herculean list. It only becomes a problem when you make no distinctions between them in the docs — like PHP.

PHP just throws a huge list of libraries at you and leaves you to figure out which one you need. There’s no overarching "Database" package — instead you get Postgres functions and Oracle functions and Firebird functions and MySQL functions, all sprinkled throughout the list.

He also comments that the entire listing is also cluttered with other functionality, things that most developers would toss aside if they came across - they just don't need them.

His point isn't without merit - there is definitely a need to reorganize things in the manual to make them a bit more "topic friendly". The documentation is already one of the most well-maintained in the Open Source community, so the content is there, maybe it's just the structure that needs to be changed.