Lots of good reasons, some of which you point out, and
some of which you neglect; here are a couple of the
ones you neglect...
- Learning. Sure, Perl is a language for getting your
job done, but there's no reason it can't also be
a language for learning. Sometimes your entire
purpose in writing something is to learn, and
sometimes you don't just want to learn how to make
it work; sometimes you want to understand the
internal details of how it works. Sure, you could
study an existing module, but sometimes writing the
code yourself gives a clearer understanding. This
is the same kind of reasoning that leads people to
read RFC documents instead of (or in addition to)
tutorials.
- Sometimes the existing module, despite technically
doing the same thing you want to do, isn't right for
your needs. Maybe its interface is needlessly
complex for a simple task; maybe the module on CPAN
uses XS, and you want a solution you can use easily
on different systems without compiling anything.
Maybe you need to be able to distribute it as part
of something and don't feel like hiring
lawyers to figure out whether the license of the
module on CPAN allows this. (I'm a programmer,
Jim, not a lawyer.) Maybe a lot of things.
In short, my criterion for rolling my own is this:
I'm aware that I'm re-inventing a wheel, and I have
a good reason for doing it. Do I see the value in
avoiding reimplentation by using existing solutions?
Yes, of course; I can't count the number of CPAN
modules I've used in the last year. But sometimes,
just sometimes, there's a reason for doing otherwise.
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/