perldoc perlmodlib
]]>
$work
, so I haven’t had a chance to respond until now. I’m going to answer everyone’s thoughts here in one post instead of trying to reply to each individually. Hopefully everyone’s okay with that.
First of all, the compliments. Ron Savage and Bull Ruppert had nice things to say, and I think them for the kind words and the encouragement. confuseAcat popped by to commiserate; it seems like we have similar perspectives, so hopefully this series will interesting to him or her.
Next, the suggestions. Aristotle offered me some other modules to investigate, so I will do that and possibly review them next installment. Christian Hansen and Mark Grimes added some useful thoughts; I’ve updated the post with brief asides based on their comments.
Finally, but probably most importantly, the criticisms. I welcome these, so definitely don’t be shy about posting them. I’ll tackle each one individually.
mst writes:
If you want to make CPAN better, a pure perl implementation of Time::Moment or starting to port some of the DateTime ecosystem would both be really helpful.
Thanks for the suggestions Matt! I do generally like to make CPAN a better place. But that’s not my primary goal in this instance. What I’m aiming for here is a way to make it easier to use dates in a casual manner— how many of us need to use them most of the time— for quick solutions. One of the things I love about Perl is that it’s so easy to do so many things. Currently I feel like dates are not easy. And they’re so commonly needed that they ought to be. So this is my attempt to address that perceived need.
Michael J writes:
No historical dates? You’ve never put dates-of-birth into a database?
Of course. But my versions of both Date::Parse and Time::Local will go back to 1/1/1000. So far I haven’t encountered anyone born before then. :-D If you’re on a 32-bit machine, I suppose you’re limited to folks born after 12/13/1901, but that still seems like plenty. Now, I know there are some historical machines out there that can’t handle negative epoch seconds (or at least I’ve read about them in various changelogs), but surely this is not still an issue for people in the modern day, is it? If it is, then I suppose I’ll fall back on the next answer.
Dave Rolsky writes:
So you never plan to write code that presents information to the user in their local time zone? Really?
Well, if I’m writing a script which will present information to the user in their local timezone, then that’s localtime
from their perspective, when they’re running the script. So I’m covered there. I’m sure there are lots of folks who have to handle this type of thing in web server code, where they really would have to convert to an arbitrary timezone. I’ve just never personally had to deal with that in my decades-long career. But certainly other people are going to have different experiences. (Although I see confuseAcat at least has a similar experience to mine: let the JavaScript handle it! :-D )
But ultimately the real answer is this: I’m not looking to supplant DateTime. I mean, obviously I couldn’t even if I wanted to, but I don’t even want to. If that’s the need you have, then my new date module is not going to be for you. And that’s okay. My module doesn’t have to be all things to all people to be useful.
Dave also adds:
Also don’t forget locale support, which is also quite useful for any app that has to support a wide variety of users.
Yes, the locale thing is a bit trickier. I think my module will still be able to be useful to many people without it, and I’m definitely not planning to try to tackle it in the initial version. But it’s something that I’d be interested into looking into further, and there’s even some basic (crude) support for it in both Date::Parse and Time::ParseDate. I don’t think it will ever be the module of choice for anything that has to do serious I18N, but I’d love to eventually get to the point where it can handle simple things like parsing strings where the names of months or days are in a language other than English. But that’s definitely a goal for the future.
Thanks again for the great comments everyone! Please know that I’m always reading them even if I don’t always respond right away. Hopefully I’ll be ready for another installment in this series next week.
Different people need different densities of help. Being able to differentiate between quick help and detailed help might be also of benefit.
]]>Such a tool would help identify peoples unconscious behaviors and provide science instead of peoples preferences.
]]>In terms of design & layout inspiration, readthedocs.org/io is very popular - so people are accustomed to its layout and possibly its layout is well conceived.
In fact someone could probably feed perldocs in to it and see what it looks like.
]]>A glitch from the past was that a lot of links didn't work on autogenerated files. I couldn't find any failures in my brief attempts, so maybe that has been fixed.
]]>A few random things I like about perldoc.pl:
- perldoc.pl has much better search, I especially like its special handling of perldeltas. Also the fact that I can input a punctuation variable in the search box and it just takes me to the right place in perlvar. I use that all the time.
- perldoc.perl.org is buggy, the bug Karl mentioned is still there and it's pretty serious. For example, go to 'bless' documentation and try clicking on the link to 'ref'. It doesn't work. It was reported *years* ago and it's still not fixed.
- perldoc.pl is more up to date, 5.30.1 was released a week ago and perldoc.perl.org still doesn't have it.
- I like that perldoc.pl provides blead documentation. Thanks to that I don't have read PODs straight from perl's git repo to check whether the documentation issue I've just found was already fixed or not. It saves time.