In digitalmars.D, you wrote: > The two most frustrating aspects were documentation and deployment. > The documents were sparse and useless and deployment was the > hugest headache I've ever experienced, in great part due to Rubygems > not working properly! > > They've probably improved it a lot since then, but it reinforced > my long-standing belief that third party libraries are, more often > than not, more trouble than they're worth anyway.
I only poked into RubyGems briefly and I had the same impression at the time. Perl's CPAN is much more mature. Much of the time, I feel as you do about 3rd party libraries. They try to do too much, are inflexible and not customizable. But many of the perl packages on CPAN are written to address a single task, are flexible and easy to use. I use several and have my favorites. Others are not worth the trouble. But this problem is going to happen to any system. Some of the packages are simply useless, poorly designed, too specific, not supported, out of date, etc. But other packages are well designed, well supported, work great. Some haven't changed in ages and work well. I think counters can help -- how many downloads, indicating popularity. How many _recent_ downloads, or a histogram of downloads by month so the user can tell if the package is out of date. Don't like the rating systems much, but that's also a possibility. An integrated bug database and forums similar to sourceforge would be very useful. You can check activity and see if the author of the package is active and keeps on top of problems. -- Brad
