If you still believe that avoiding dependencies at all costs is a viable strategy, consider how much code you would have to write to clone del.icio.us in 24 hours. Can you get that all correct writing all of that code by hand?
Me neither—not because I can't (eventually) get it all right, but because I have much, much better things to do than to write yet another dispatcher and worry about all of the fiddly bits of encodings and character sets and tainting and verification that everyone else everywhere needs and uses.
By all means let us explore possibilities of removing the walls against which people installing dependencies bang their heads against, but let us also never fail to wave the banner of "We write glue code, darnit!" proudly. Of course we glue together libraries. It saves us the time and energy and debugging and frustration we should otherwise be spending on inventing new things, or at least better things.
In a world without Moose and Catalyst and Dancer and Plack and even and especially TAP, I don't use Perl, I don't write books and articles, I don't publish CPAN modules, I don't contribute to a common ecosystem from which other people can draw.
Don't like the way my freely available and freely usable and freely modifiable and freely redistributable code works? You get to write your own glue. Me? I'll be off solving the next problem.
On the one hand I entirely agree.
On the other hand however, I am given to wonder how much code there is around the place that pulls in DateTime and its entire deptree, simply because the author didn't know how to use localtime/POSIX::mktime, or because core's POSIX.xs doesn't provide a wrapper for strptime. Perhaps everyone else does very much weirder date/time maths than I do, but personally I've never yet encountered a problem that cannot be simply solved using localtime/gmtime/mktime, possibly combined with strftime/strptime.
Yes I know core doesn't wrap strptime, and the CPAN distribution POSIX::strptime is annoyingly broken. I have plans to put strptime in core's POSIX.xs as soon as the dust from the 5.14 release cycle has settled.
<DateTime-rant/>
We really don't need strptime in POSIX.xs since it's already in Time::Piece, perhaps the problem is people don't know about Time::Piece / know that Time::Piece is in core now. The perlfaq also didn't know that until recently.
I'd like POSIX.pm more if I hadn't read the code. It's useful (at times, indispensible), but... wow.
This feels like a strawman. That is, how many people actually argue for "avoiding dependencies at all costs" (which is obviously unreasonable) as opposed to "avoid unnecessary dependencies" (which sounds very reasonable)?
But I don't want to set up a paper target myself. You say, "There are so many good reasons to reuse other people's code." I say, "Absolutely." But I also say, "There are at least two good reasons to write your own X. First, to learn. Second, to make a better X (or an X that fits your needs better)." (Yes, I can learn by reading existing code, but reading is more passive than writing. Yes, maybe the thing I write won't be as good as what already exists, but we could say that about a lot of things. And at least sometimes we would be wrong.)
We can overdo the mantra of "code reuse" just as we can overdo the "minimal dependencies" slogan.
tl;dr - Writing your own is not always a mistake.
Final disclaimer: you and I have had this argument before.
However, Time::Piece makes the same mistake most other CPAN wrappings of strptime make; it tries to return a list of values and takes a string as a pure literal value. This makes it hard to perform incremental parsing suggested by
https://rt.cpan.org/Ticket/Display.html?id=66519
It also makes it impossible to write a prefix-eating parser. At the C layer, strptime(3) tells the caller how much of its input string it consumed, allowing you to write an incremental prefix-eating parser that walks along the string. None of the CPAN wrappings of strptime allow this from perl; they all eat the entire string returning no hint.
It is my intention that the POSIX.xs wrapping would fix both of these shortcomings.