Brendan Byrd

• Website: metacpan.org/author/BBYRD
• About: Programmer since I was 5. Perl since 1996. Parent since 2009.

Recent Actions

• Commented on The Four Major Problems with CPAN
  This discussion was held several times over the years. A solution INSIDE the CPAN package is pointless here. For one: It doesn't address anything about EXISTING packages, which are 99% of the problem, new modules are rarely having these problems....
• Commented on The Four Major Problems with CPAN
  RE: 2nd reply: Yes, I completely agree. But, I don't completely understand it. To me, it's easier to just provide some code and put out a bug report. Writing an entirely new module is harder. 1. I've heard about the...
• Posted The Four Major Problems with CPAN to Brendan Byrd

  First of all, I love CPAN. CPAN was the first of its kind, to provide an extensive and official library of modules that support the language itself. CPAN is very much a part of Perl as much as regular expressions are. Without CPAN, Perl would never be as versatile or useful as it exists…

Comment Threads

• Paul "LeoNerd" Evans commented on The Four Major Problems with CPAN

  As the author of two of the six modules you point out in the first place, I feel I should write a little reply here.

  As to the Socket vs. Socket6 question: Originally, Socket6 was written by someone to provide the various IPv6-related functions missing from core's Socket. Eventually I got around to taking over core's Socket and adding them properly there where they should be. This now makes the Socket6 module totally redundant. Should that now be marked? If so, where? I have no write access on Socket6, so I can't write it there. I could notate it in Socket, if anyone would think to l…

• jakoblog.de commented on The Four Major Problems with CPAN

  See this MetaCPAN feature request from one year ago. The more scoring indicators to be used for ranking in MetaCPAN, the better. How about explicit statements like "I prefer module Foo in favor of module Bar" to be used for ranking and as guides too?

• asknet999.myopenid.com commented on The Four Major Problems with CPAN

  Other than voting, metacpan or cpan site should include a counter that tells how many times a particular module has been installed or downloaded. This is one of the measurement used by many users when there is a huge catalog. For example, mobile apps installed from app store has this counter, the greasemonkey scripts installed from userscripts.org has something similar.

  What I believe, is CPAN model should be similar to Mobile app store, where the app store gives information like; reviews, rating, no of downloads, other modules by author, suggested modules and so on.
  …

• larryl commented on The Four Major Problems with CPAN

  @brian d foy said:

  > I am constantly and consistently surprised about how many
  > people do not first try to work with existing projects.

  For me, GitHub has been the single biggest factor in lowering the barriers to entry to making contributions to existing CPAN modules. I find I'm far more likely to contribute changes to an existing module when all I need to do is fork it and send a subsequent pull request. Maybe if more source code was handled via GitHub (or similar mechanism) there might be less of a tendency to reinvent the wheel as opposed to enhancing existing co…

• Buddy Burden commented on The Four Major Problems with CPAN

  Yet Another Problem with the ideas (not that I wish to discourage you--definitely keep pursuing these ideas, as they're much needed--but just to make sure you're thinking of all the issues) is that, while sometimes there is a "right" and a "wrong" module, sometimes there isn't. That is, sometimes there are two modules that both do the job and there just isn't a clear reason to prefer one over the other. Perhaps one is OO and the other isn't. Perhaps one has more features but the other has a simpler interface. Perhaps one works well for A but not at all for B, while the other…