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

[Paul E Condon]

On 20091017_091238, Tkil wrote:
> >>>>> "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.

I've been in several situations where I've used libraries for
computational problems. I found that a difficult aspect of using a
library function was determining what the routine actually did with
the corners, and how, precisely to specify what your bound is. Typical
statement in the documentation for a routine is 'X must be between A
and B' and not a word about X==A or X==B.  English is an inadquate
language for documentation. Maybe some other natural language would be
better. English is the only language I know well enough to complain
about. Writing test programs to determine what a badly documented
library routine actually does with a corner case is a real drag. For
number ranges, I prefer lower bounds to always be closed and upper
bounds to be always open. But that doesn't seem to be the case always.


-- 
Paul E Condon           
pecondon at mesanetworks.net