Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Ovid's "Please Stop Using Perl 3"

by nevyn (Monk)
on Sep 06, 2006 at 16:25 UTC ( [id://571498]=note: print w/replies, xml ) Need Help??


in reply to Ovid's "Please Stop Using Perl 3"

Ovid's solution: Use more CPAN. He says "Most of the tools you need to build most common applications have already been written and are waiting for you on the CPAN."

There are a couple of problems with this solution, IMO. Some of the modules in CPAN aren't that great (some, like, Text::Netstr are just horribly broken) and there's no obvious way to seperate the good from the bad, or even say "please don't use this it's broken".

Also perl tends to make hacks really easy, couple that with the fact that adding dependencies is generally painful and it's often easier to ignore/not-think-about the corner cases and just paste some simple code in.

One solution might be to make installing from CPAN much easier (for a packaged distro, say), but people have been saying that for a long time ... and perl-DateManip is in basically every distro. and I still see code avoiding it.

--
And-httpd, $2,000 security guarantee
James Antill

Replies are listed 'Best First'.
Re^2: Ovid's "Please Stop Using Perl 3"
by davorg (Chancellor) on Sep 07, 2006 at 14:50 UTC
    perl-DateManip is in basically every distro. and I still see code avoiding it.

    That's because it's horrible. Even the author doesn't recommend that you use it:

    Is Date::Manip the one you should be using? In my opinion, the answer is no most of the time. (Should I Use Date::Manip?)

    Please get into the habit of recommending DateTime.pm and its friends. That's the best way to handle dates and times in Perl.

    --
    <http://dave.org.uk>

    "The first rule of Perl club is you do not talk about Perl club."
    -- Chip Salzenberg

      From the same page:
      On the other hand, if you want one solution for all your date needs, don't need peak speed, or are trying to do more exotic date operations, Date::Manip is for you. Operations on things like business dates, foreign language dates, holidays and other recurring events, etc. are available more-or-less exclusively in Date::Manip.

      This is the reason I recommend it, the speed is rarely a factor (for what I do, YMMV). The API that I use in 99% of cases is 2-3 functions.

      Also AFAICS if you have a "Date and time" as a string there is no DateTime constructor to pass it to Date::Manip::ParseDate "just works". Getting a readable version of the data out also seems much harder than calling Date::Manip::UnixDate too.

      But all of this just proves my other point, if you want an answer to the question "Which module should I use to do X" you can't easily get an answer ... you have to either pick a module and hope, or hack some code in directly that you know/think solves your problem.

      --
      And-httpd, $2,000 security guarantee
      James Antill
        Also AFAICS if you have a "Date and time" as a string there is no DateTime constructor to pass it to. Date::Manip::ParseDate "just works".

        The point is that DateTime is a family of modules. To do extra stuff, you install the appropriate module. In this case you want DateTime::Format::DateParse.

        But all of this just proves my other point, if you want an answer to the question "Which module should I use to do X" you can't easily get an answer ... you have to either pick a module and hope, or hack some code in directly that you know/think solves your problem.

        The Perl DateTime project was set up to address exactly that problem (well, at least, in this one area). Sounds like they may as well have not wasted their time if people like you are just going to ignore their work.

        --
        <http://dave.org.uk>

        "The first rule of Perl club is you do not talk about Perl club."
        -- Chip Salzenberg

Re^2: Ovid's "Please Stop Using Perl 3"
by Anonymous Monk on Sep 06, 2006 at 17:37 UTC
    One solution might be to make installing from CPAN much easier (for a packaged distro, say), but people have been saying that for a long time ... and perl-DateManip is in basically every distro. and I still see code avoiding it.

    Hmm... I can't find it on my system. I've got perl5.6.1; maybe that's too old?

    Has the perl community finally standardized on a single, reliable date and time module? Every place I've ever worked, there's always been some home-grown date/time solution, and when I suggested downloading something from CPAN, no one could decide on what to download, so they had an excuse to maintain the status quo. *sigh*

    If perl5.8 has a standard date/time module, that's reason to upgrade right there, IMHO. Is Date::Manip it, or was that just your favourite choice in yet another CPAN holy war?

      Date::Manip is ancient and was highly regarded for being very flexible (especially at parsing date strings of unknown format) but noted for being quite "slow". It certainly isn't a "new date/time module" that people are trying to standardize on.

      I still see quite a few different date/time modules being suggested so consolidation is not working very well yet from my perspective. I recall that there is work being done on some Holy Grail suite of Perl date/time modules but don't recall the namespace (it was something really simple like DateTime::*), which might say something about why consolidation isn't finished. I certainly don't have a good idea where I'd go to figure out which date/time module currently has the most support and that is part of why I don't use any date/time modules.

      I just use localtime, gmtime, and Time::Local and sometimes POSIX::strftime() and would find learning some module time-consuming and fully expect to find using the module to be quite frustrating. But I'm sure most peoples' mileage will vary.

      - tye        

        Well I've never cared about the "slow" aspect, I often want it where I have a string which represents a "date and time" and I just pass it to ParseDate() and that "just works".

        In many cases strptime would work and I might use that with strftime etc., if it was in core ... but it seems worthless to pull a module in for strptime, when I can just pull Date::Manip in instead.

        How do you parse date/time strings?

        --
        And-httpd, $2,000 security guarantee
        James Antill
        I just use localtime, gmtime, and Time::Local and sometimes POSIX::strftime() and would find learning some module time-consuming and fully expect to find using the module to be quite frustrating. That's what I tend to do, too. Time::Local and POSIX both seem to be part of the core distribution, as of 5.6.1. This is a good thing.
      DateTime is the best date time module. Comprehensive but nice object-oriented interface over quick-and-dirty. Handles timezones. Heck, it handles tons of different formats and even other calendars. There is a lot of modules to install from CPAN but you will be happy once you get them installed.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://571498]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2024-03-19 07:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found