[lug] can't make this stuff up, folks...

Tkil tkil at scrye.com
Sat Oct 17 09:12:38 MDT 2009


>>>>> "David" == David L Anselmi <anselmi at anselmi.us> writes:

David> I see a lot of "why use a library that I can write myself"
David> coding.  I don't know whether good libraries are that hard to
David> come by. 

I wrote a blurb on this topic a few years ago...

  http://www.perlmonks.org/index.pl/?node_id=359220

(It makes a bit more sense if you already know that CPAN is the
"Comprehensive Perl Archive Network", the collection of perl libraries
that people have contributed over the last 20 years or so.  In this
context, "use CPAN" means "don't code it yourself, use a library".
The whole thread has some interesting points to make, but here's my
take on why there's not as much library use as there "should" be:)

  > I would prefer it if the first answer was not "look on CPAN, and
  > don't attempt to try yourself."

  As others have pointed out, that's not always the first answer. The
  "look on CPAN" answer does tend to get used when people start
  asking: "How do I handle this corner case? What about this special
  situation?" It is exactly this sort of "institutional knowledge"
  that a repository such as CPAN is perfect for accumulating.

  The other reason that long-time users often resort to telling
  novices to "use CPAN" is because they want to provide a working
  solution, but they don't have the time or energy to teach the novice
  all the way up through the ranks.

  Finally, I find that there are many modules on CPAN that are right
  at the boundary where "work required to understand the interface" is
  just about equal to "work required to replicate their functionality
  'by hand'".

  What tends to happen is that it is easier to open-code a solution
  that handles 90-95% of the cases; it's those last few percentages
  that require ugly special code, pleas to Seekers of Perl Wisdom, and
  responses to "use CPAN" and/or "let's make that a module".

  The latter, however, eventually grows enough hair that when the next
  novice comes along, looking to solve the first 90% of their problem,
  says "wow, that module's too complex, I can just solve it with my
  own code like so..."

The last three paragraphs are the core of my theory on lack of library
use.

(It's also that proper refactoring to allow for re-use is /hard/, and
often requires concepts and constructs that allow for that last 5% to
be handled, while making the first 95% much more difficult and complex
than it would otherwise be.)

t.



More information about the LUG mailing list