views:

408

answers:

7

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.

A: 

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.

Alister Bulman
+9  A: 

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.

Kent Fredric
Yup. And yet somehow it still mostly works. (At least crappy VB code was mostly invisible.)
le dorfier
the infestation is self sustaining sadly, everyone reinvents the wheel, but doesn't share it so others don't have to.
Kent Fredric
I don't really think this is why PEAR lacks full adoption.
jmucchiello
+2  A: 

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

A: 

PEAR is not common, nor popular.

Csaba Kétszeri
A: 

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.

uuɐɯǝʃǝs
+5  A: 

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

Tom
+1 and seconded on PEAR::DB/postgres. I've dealt with the same problem. It's only reinventing the wheel when the standard libraries do it efficiently already.
Frank Crook
Bullet point #2 is the big killer for me. PEAR code is bloated because it has to deal with a wide variety of situations. Most of the code gets read and interpreted by every page on your site even if your are only using a small part of it.
jmucchiello
A: 

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?!)

Sam