How common is PEAR in the real world?

Question

I have looked at a good deal of other peoples source code and other open source PHP software, but it seems to me that almost nobody actually uses PEAR.

How common is PEAR usage out in real world usage?

I was thinking that maybe the current feeling on frameworks may be affecting its popularity.

Answer 1

PHP programmer culture seems to have a rampant infestation of "Not Invented Here" syndrome, where everyone appears to want to reinvent the wheel themselves.

Not to say this applies to all PHP Programmers, but them doing this apparently far too normal.

Much of the time I believe its due to lack of education, and that combined with difficulty of hosting providers providing decent PHP services.

This makes getting a workable PEAR installation so much more difficult, and its worsened by PHP's design structure not being favorable to a modular design.

( This may improve with the addition of namespaces, but have yet to see ).

The vast majority of PHP code I see in the wild is still classic amateur code interpolated with HTML, and the majority of cheap hosting that PHP users inevitably sign up for doesn't give you shell access.

Answer 2

In my (limited) experience, every PEAR project that was potentially interesting had major points against it:

• Code is targetted at the widest audience possible. There are hacks in place all over the place to deal with old/unsupported PHP versions. New useful features are ignored if they can't be emulated on older versions, meaning you end up lagging behind the core language development.
• Any given project tends to grow until it solves everyone's problem with a single simple include. When your PHP interpreter has to process all of that source code on every page hit (because the authors may not have designed it to be opcode-cache-friendly), there is a measurable overhead for processing thousands of unused lines of code.
• Style was always inconsistent. It never felt like I was learning generalizable APIs like in other languages.

I used to use PEAR::DB at work. We discovered that most of our scripts spent their time inside PEAR code instead of our own code. Replacing that with a very simple wrapper around pgsql_* functions significantly reduced execution time and increased runtime safety, due to the use of real prepared statements. PEAR::DB used its own (incorrect at the time) prepared-statement logic for Postgres because the native pgsql_ functions were too new to be used everywhere.

Overall, I feel like PEAR is good as a "starter library" in many cases. It is likely to be higher quality code than any individual will produce in a short amount of time. But I would certainly not use it in a popular public-facing website (at least, not without a lot of tweaking by hand... maintaining my own fork).

Answer 3

Im my opinion PEAR is a good project but lacks people who want to work and keep working on it, most of the packages have inconsistent coding practices (I do not mean coding style) and there are lots of TODO's in the whole thing.

I find it useful sometimes for coding stuff I didn't know existed yet, like custom country validation functions and so on, otherwise I'm better served with any available framework out there (like CodeIgnite or Zend Framework).

Answer 4

The Pear library is the kinda stuff that just sits there, plugging away, with very little glory. If you are looking for something that it can do, and there's nothing more specifically targeted in the framework that you are using - go use it.

I've been working on a dating site for the last two years - and there's at least 65 pear-sourced files I've used, and are still live there today. Some, like the pager or html_Quickform will be overtaken by new code as it's updated, but for others there's just no need.

Answer 5

PEAR is not common, nor popular.

Answer 6

I tried to use PEAR so many times, but it lacks the umpphh to commit.

I prefer Zend Framework which takes the approach of 'loose' type, use only what you want.

Answer 7

PEAR is not common, nor popular — but it is good, and I'd recommend it to anyone.

(I do agree with Tom in that it doesn't feel like a single, unified, API; but then, this is PHP … one wouldn't like to see it getting above its station as an interpreted hack language now would one?!)