What’s Wrong with PEAR?
Disclaimer: 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:
PEAR
Allows PHP to exposé what are perhaps the
worst most dysfunctional and retarded code…
in an easily downloadable/installable form.
These kind of statements are nothing new. Regardless of the group of developers who work on developing and improving PEAR, the community project continues to be the object of contempt by people who prefer to write the project as something “that sucks” rather than making any contributions to bringing the project up to whatever their standard of “not sucking” is.
The core of the issue, I believe, is that people simply do not understand PEAR. To address this, I’ve written an article which will be released in the September edition of the PHP Architect magazine which aims to give better understanding of the project as well as the community infrastructure.
I would like to dedicate this blog entry to people who think that PEAR does suck, and open up the discussion to what it is exactly that sucks. PEAR has issues, but I truly believe that most of the trash talking that is done is mainly due to the ignorance. So please, if you have issues, whether technical or package specific feel free to vent here.
I’ll start the fun.
Issue: PEAR is PHP4
Resolution: All PEAR packages work in PHP5 without E_STRICT. To maintain backwards compatibility there is nothing that stable packages can do about this. However all packages moving forward will be required to run under E_STRICT PHP5.
Issue: PHP Releases were delayed or screwed up by the bundled PEAR release.
Resolution: This was fixed with PHAR archives.
Issue: The PEAR community is slow and bureaucratic
Resolution: Create your own PEAR repository
Issue: PEAR (more specifically the Date class) hinders PHP’s ability to use the class names it wants in future versions
Resolution: This is a problem. However, the popularity of the PEAR::Date class is more of a symtopm of the lack of PHP namespaces. PEAR is working to resolve this, but a simple change of the Date class name won’t help anything.
August 4th, 2006 at 11:13 am
PHP releases were delayed only *ONCE* because of PEAR. And it was only because nobody told me about the release date.
Laziness of the some RM are the main causes of the delays.
August 4th, 2006 at 11:15 am
Hehe .. I guess PEAR does feel like its getting hit alot for no good reasons. I wrote an article that sounds like yours for the international php mag a while ago too:
http://phpmag.net/magphpde/magphpde_article/psecom,id,745,nodeid,21.html
Several of the things I promised there did not happen though. Like user comments or a wiki. So I guess we are quite slow indeed ..
August 4th, 2006 at 1:00 pm
Aaron.
I agree with you. PEAR is better then it’s reputation. But a big problem is the lack of:
a) good tutorials / documentation
b) good marketing (see a)
c) good projects using it (see b)
I think, the most people just don’t know how to use PEAR. Less users means less a), b) and c). And if more people would use PEAR, maybe there would be more maintainers.
August 4th, 2006 at 1:18 pm
I am not an experienced PEAR user, but the three separate times I’ve tried to use it I’ve had problems with extensibility. The only way to solve them was to change PEAR classes (NO, subclassing or other techniques wouldn’t do it), which of course I didn’t want to do. Those three times (with three different packages) were enough for me, now I always looks elsewhere first, and only resort to PEAR when there isn’t any other option.
Besides, there is a big difference between PHP5-compatible code and PHP5 code. If given a choice, I prefer the latter.
Regards
August 4th, 2006 at 2:10 pm
Aaron Wormus’ Blog: Whats Wrong with PEAR?…
…
August 4th, 2006 at 2:27 pm
Perhaps PEAR reputation is worse than it deserves and the part about PEAR allowing “worst most dysfunctional and retarded code in an easily downloadable/installable form” is exaggerated. However, from my point of view the packages at pear.php.net have very differing quality. While some of them are examples of PHP at its best, other packages are complete rubbish.
I’m not saying this to offend any of the contributors to PEAR - I’m sure they all have the best of intentions but in some cases their code brings more trouble than it solves.
This is also part of one of PHP’s greatest problems - a great deal of the users have never done any programming before they begin with PHP. They look at poorly written code and think that is the way you should code. Unfortunately some of this code is available for download at the official PEAR repository.
August 4th, 2006 at 3:04 pm
Pear is terrific - I use it all the time. However, PEAR has two problems”
1 - lack of cogent, easy-to-follow tutorials. You are expected to be a terrific programmer and dig in to the source code if you have any questions. That’s terrific for many but it will be a a DEFINITE stumbling block to new developers.
2 - smarta** feedback on the PEAR forums. At times the help is great and could come from no other place. Other times, I get the most asinine comments (from at least one of the people who built the package!). It’s almost like they dare you to ask a question and if you do, you are a doofus who couldn’t boil water.
I’ not going to stop using it but I have stopped using the forums unless abosolutely necessary.
August 4th, 2006 at 3:41 pm
I agree with many of the statements here. Definitely the lack of good documentation. Sure there are some documents on the source code but that doesn’t help when the description is bad or the context of use is not shown. Building a simple wrapper to show functionality is rather easy and would come rather easily by writing unit tests. This is the main frustration I feel most people have with PEAR.
Next is that when help is offered to several projects they are dormant and you never get responses. Sure a developer would like to get involved helping write documentation and fixing bugs but it really doesn’t help when there are classes and packages where the person really does not want help and would rather let the package go into oblivion rather than keeping it going.
August 4th, 2006 at 3:43 pm
To the point of “PEAR is PHP4″:
That it probably won’t run under PHP5 is not the problem. The problem is, that PEAR is not using the new oop features which PHP5 provides, while it is demanding OOP programming style with the poor object support of PHP4.
So it is not surprising that the code quality of PEAR projects is very bad.
August 4th, 2006 at 5:32 pm
I’ve had various opinions about the quality of some PEAR packages, but overall I think the code is decent. The biggest mistake (I think) has been not to have a more user responsive site: the official documentation desperately needs user comments at least and even better would be to wikify the documentation itself. On some of my most used packages, the documentation is out of date compared to the code and I would be happy to ammend it or note the discrepancy…
It makes it feel as thought to be a member of the PEAR community, you have to actually be a developer of a package. This seems to me to throw away lots of useful user contributions.
August 4th, 2006 at 5:38 pm
I do not use PEAR because:
1) All the packages are released in a continuous flow… Can you imagine the mess if PHP team would release the new version of the modules the same way?!
2) The quality of the code is… Have you seen Zend Framework?
3) Will my grand children see a PEAR for PHP5.0 or PHP6.0 branch?
4) Documentation is crappy
5) Why do we have different packages for doing the same thing?
6) I do not see the goal of PEAR: a framework (For some packages) or a library of classes?
7) Some packages are stable other are not.
…
I think the main issue is the release strategy…
August 4th, 2006 at 5:42 pm
Zend framework is going to kill PEAR so why invest on PEAR?!
August 4th, 2006 at 7:03 pm
I think it’s premature to say Zend Framework is going to kill PEAR. I do think that PEAR’s response to ZF should be to emphasize the ways in which they are different.
PEAR is NOT a framework. It is a library of classes. There are multiple packages for doing the same thing and there ought to be more! Think about it: ZF is going to be a framework that is corporately controlled. PEAR should in response be more CPANish: open to contributions with a process focusing on community responsiveness and agility. If people want to contribute, let them! And if you’re worried about overall code quality, give the QA team keep people out of the installation channels unless certain requirements are met…
Trying to maintain control is killing them, I think. Look at the Tree class. Is it just me or does PHP badly need some Abstract Data Type classes (Tree/Graph, Stack, Queue, etc)? There is a Tree class in PEAR, but it has been at the same beta point release since 2003 (from memory here, too lazy to look it up). I’ve thought about trying to take over this package since I’ve used it and the functionality is incomplete and buggy. But I have signifigant reservations about the design! I’m guessing (from reading the PEAR mailing lists) that the response to major changes would be negative (don’t break BC) and the request to start a new ADT_Tree class would also be negative (don’t duplicate functionality).
That’s fine, I understand the reasoning behind both those decisions. But the result is I just wrote my own lightweight tree class anyway and don’t contribute the code to the community at large.
As the default repository for “modules”, PEAR can prosper. As some sort of framework with one true way of doing things, I don’t see them going head to head with ZF…
August 5th, 2006 at 6:06 pm
The real reason that those involved in PEAR do not see the problem with PEAR is because that problem is a design one, not a code one. The entire design of PEAR as neither a framework nor a repository is flawed. And the code, with some exceptions, is mostly 1st Generation PHP OO thinking that is simply not well designed. PEAR_Error was perhaps the worst example of this and that design cruft still permeates PEAR.
It is much harder to refactor bad design than bad code. The world has moved on, while PEAR continues to hone solutions that appeal to small groups of specific style of library. That kind of “I like template library X best” thinking is also very 1st Generation PHP. I am sure that PEAR will idle on with its bureaucracy for some time to come, providing a little value here and there.
August 6th, 2006 at 12:38 pm
Christopher: I would like to point out that nothing prevents anyone from writing a package that is designed differently. PEAR is library of components, it does not impose a given design.
August 7th, 2006 at 6:49 am
—
1) All the packages are released in a continuous flow… Can you imagine the mess if PHP team would release the new version of the modules the same way?!
—
This is a ridiculous statement. You could apply the same to any linux/unix/bsd distribution. Oh all the packages in Redhat are released separately. It’s CHAOS!!! Please, you’ve got a package management tool, what more do you need?
August 7th, 2006 at 7:00 am
This stuff is too easy….
2) The quality of the code is… Have you seen Zend Framework?
The quality of the code is… variable! Welcome to the world of open source. Have you seen the php modules?
3) Will my grand children see a PEAR for PHP5.0 or PHP6.0 branch?
I think you’ll find Pear packages, unless otherwise noted, will remain backwardly compatible as long as people are still developing on PHP4. I develop on PHP4 because for many webhosts that’s all they offer.
4) Documentation is crappy
Read the API docs. Submit your own ‘howto’ documentation to the maintainers.
5) Why do we have different packages for doing the same thing?
Because there is more than one way to skin a cat. Do you really want pear packages dictating how you code?
6) I do not see the goal of PEAR: a framework (For some packages) or a library of classes?
How is this for a goal: Help you write less code and get results faster. That’s what PEAR does for me.
7) Some packages are stable other are not.
If there is an unstable package you’d like to use. You can contribute your time and talents into
Welcome to the world of open source. I would argue that the PHP imap module is no longer maintained. But then I don’t think it ever got much attention in the first place. If you’d like to contribute your time and talents…
August 7th, 2006 at 8:28 am
PEAR group need to apply some quality control to their website and what goes into it. When I go to search pear.php.net for packages that might be of use to me, I can’t tell what’s good code, bad code, stable or alpha. I usually give up after half an hour of wading through unfinished packages or trying unsuccessfully to make sense of the automatic documentation.
PEAR website needs to direct me towards the useable packages with readable documentation.
August 7th, 2006 at 3:50 pm
Aaron,
PEAR historically has suffered from poor quality code - both in terms of bugs and in terms of design. Things are much better these days, and now that there are more modern tools such Sebastian’s PHPUnit available to PEAR developers, there’s no reason that PEAR shouldn’t provide good code going forward. Documentation and design, on the other hand, still leave a lot to be desired.
However, PEAR’s problem is that it’s based on a fundamentally flawed paradigm. The decision to make PEAR != CPAN for PHP was at the time, and always will be, boneheadedly stupid (Lukas, are you reading this?). The decision to not allow competing packages into PEAR made PEAR totally irrelevant to most PHP programmers. Instead of PEAR becoming *the* source of packaged PHP modules, it’s spent years as a nepotistic hive of inbreeding, squabbling children.
Just look at the success of RubyForge and Ruby’s gems to see the monumental size of the mistake that PEAR made, and what PEAR could have been.
If PHP falls from grace and is replaced by Ruby (a move I’m already seeing amongst my customers, alas), this one decision about PEAR above all others will always be the reason why.
Best regards,
Stu
August 7th, 2006 at 4:15 pm
Stu: nice of you to drop by
I agree with a lot of what you’re saying. Contrary to popular opinion there is no “non-competing” package rule.
However I would somewhat agree that the fact that PEAR set up the guidelines so that they could ensure high quality, they also bear the responsibility for the poor quality of some of the code.
As far as a dump of tons of classes, you can look at PHPClasses, and ask if you would prefer that.
August 7th, 2006 at 4:43 pm
Aaron: somebody proposing a competing package will be given a hard time
PHPClasses is always given as a counter example but I’m pretty sure there can be a middle ground.
August 7th, 2006 at 4:58 pm
The key point is that we do not allow redundant approaches to the same problem. We do however allow redundant different approaches to the same problem. This is a key distinction. And so for example we have 4 different ways templating can be done.
But maybe I just am Ruby’s biggest hero?
August 8th, 2006 at 11:20 am
Heya Aaron,
Heh - the problem with PHPClasses is more the lack of a packaging standard. So I guess my ideal replacement for PEAR would be to take the PEAR packaging system, make unit testing and documentation somehow mandatory, add a rating system so folks can vote down poor code, and then open the doors.
Best regards,
Stu
August 8th, 2006 at 3:00 pm
What is stopping you from uploading PEAR packages to PHPClasses? Anyways, yes we chose to create a development community. What you are proposing is however trivial to create at this point using a channel. All you need to do is write your own channel server or extend Greg’s channel server to check for tests/docs and user voting. It would take no more than 1-2 weeks for a competent dedicated programmer. If the future of PHP depends on this, I am sure there will be people who do it.
And guess what .. I would very much welcome this!
August 19th, 2006 at 12:46 am
What’s Wrong with PEAR?…
- Missing maintenair because too many think make better than other, and prefers restart an new code than share and contribute ton an existing.
- Docbook is hard, yes, but it’s a false reason, some user are ready to dockbookise all proposed doc.
……
August 19th, 2006 at 12:46 am
- Missing maintenair because too many think make better than other, and prefers restart an new code than share and contribute ton an existing.
- Docbook is hard, yes, but it’s a false reason, some user are ready to dockbookise all proposed doc.
- Doc missing : yes and is became required to have a stable status.
- Doc missing : yes but how many package user have propose to developper to contribute with doc, tuto, sample … no many. Users take and away.
- Docbook is better (because can be include in the translation process) but is not the only way to propose a doc for a package, many maintainer use a private wiki.
- France is a republic, Belgium a realms. French people choose the president and are always to talk negative about him. In Belgium , we can’t choose the king, and lot of people appraciate the king.
Yes zend Framework would progress better and faster than pear, but some elite, choosed (in closed friend ring) to have something to do in the project, other can olny be user.
August 23rd, 2006 at 1:15 pm
[…] I just listened to the latest pro-php newscast (I didn’t listen to the old ones, but love the new format). Haven’t listened in a while and was happy to hear my blog entry discussed. I am planning on writing a follow-up to that. You guys need better show notes, some links maybe? […]
November 30th, 2006 at 4:35 am
I thought I knew something about installing software, until I met PEAR. It took me 2 days to set up a linux computer with Apache2, PHP5, Perl and several other items. I’ve never used linux before that. I’ve been on PEAR for three days now and I have only gotten past the download of the correct .phar file to correct the bad one in PHP5’s compliation. Now I still have no idea how to actually “use” it or and I don’t really believe that PEAR is completely or correctly installed…what’s my process for testing it? Yeah, crappy guides that are incomplete and refer to too many versions of the install and set-up process…how about standardizing it? Like perl and python for windows (which is what I am trying to install it on). Nothing should be this aggrevating…except marriage.
January 13th, 2007 at 10:31 am
Hi! Very nice site! Thanks you very much! ePBL9pieYVAC
January 23rd, 2007 at 7:52 pm
ejtsndye
February 14th, 2007 at 5:39 pm
Low levels of the male hormone testosterone, which may affect the desire for sex. Your physician can perform a blood test to measure your testosterone levels. 4 man medication
March 1st, 2007 at 2:53 pm
I admire you on the willingness to share this info with others - good luck!
March 10th, 2007 at 12:59 pm
Luogo molto buon:) Buona fortuna!
March 10th, 2007 at 12:59 pm
Luogo molto buon:) Buona fortuna!
March 17th, 2007 at 9:48 am
Lo trovo piuttosto impressionante. Lavoro grande fatto..)
March 19th, 2007 at 1:27 am
Logging into this website should be a requirement for anyone knowledgeable on earth these days…
May 24th, 2007 at 6:35 pm
mukezhfd
June 9th, 2007 at 9:30 pm
There are several bad credit loan on the ton
for willpower place trades. In herbal, cheat contrary gloves
to bond any exhibit that they improve.
September 20th, 2007 at 8:08 pm
I have no idea if my experience in instructive for why people dislike PEAR. In fact, given the level of spam above me, I wonder if this comment will even be read.
So I’ll keep it short.
I tried to use the PEAR installer the “right way”, after not understanding it and hacking libraries in the “wrong way.” For whatever reason I wanted to configure it with some directories in non-standard places, and the PEAR installer (go-pear I think was what I was running) appeared to support this. So I did this, got my installation in a bad state, and asked for help on #pear.
So far, it’s not really the reason why I dislike PEAR. But in #pear I was scolded for picking non-standard installation paths and made to feel that the PEAR experts really didn’t want to help anyone who hadn’t intuited a limitation (only using standard paths) that was not clear from the executable. So I decided I didn’t like PEAR.
Maybe I’m being small-minded. I do use individual PEAR libraries at times, which I usually install by hand if I can do so. But that experience was the difference between me being a reluctant consumer of certain code and me being an enthusiastic advocate of the idea behind PEAR.
February 7th, 2008 at 4:58 am
I couldn’t understand some parts of this article s Wrong with PEAR?, but I guess I just need to check some more resources regarding this, because it sounds interesting.