Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Favourite modules March 2004

by Juerd (Abbot)
on Mar 07, 2004 at 17:02 UTC ( #334621=perlmeditation: print w/ replies, xml ) Need Help??

Dear it in more than one way doing friends,

After Favourite modules March 2002 and Favourite modules April 2003, I think it is time to list my favourite modules for March 2004.

These lists are a very good way to learn about modules you didn't know before. This and other things have influenced my list of favourite modules. The most important reason for the big difference with last year's list is that I used sort to get the modules in a more accurate order.

sort { print "A: $a\nB: $b\n> "; { A => -1, B => 1 }->{uc substr <>, 0, 1} } @foo;

For each choice between modules, I chose the one I liked better. I found that the one I like better isn't always the one that I use more often. According to Perl, this is my list for this year: (As before, excluding pragmata and my own modules)

  1. LWP
  2. B::Deparse
  3. Carp
  4. Template
  5. Benchmark
  6. DBI
  7. DBD::SQLite
  8. WWW::Mechanize
  9. File::Slurp
  10. File::Find::Rule
The modules that were in @foo but didn't make it are (in alphabetical order): Class::DBI, HTML::TreeBuilder, IPC::Run, MIME::Lite, Regexp::Common, Text::Reform.

I'll try to explain the difference with my list of April 2003:

  • I haven't used IPC::Run a lot. I think I loved it mostly because I was used to open2/open3.
  • LWP apparently is cooler than I realised. WWW::Mechanize is new and I really love it. I think it influenced my thoughts on LWP.
  • To my surprise, Regexp::Common is not as useful as it seemed. It has many very useful regexes, but in a year my own regex skills improved. For most of the situations in which I was about to use a regex from %RE, that regex was slightly different from what I had in mind. I think I used only the IP and hostname matching. The enormous number of tests also made me like it a little less: it takes too long to install.
  • Having done less email related programming, I almost even forgot about MIME::Lite.
  • Template Toolkit is new in this list. It has simplified working together with non-programmers and forces me to code in a more structured manner.
  • I have always liked File::Slurp, but with Uri Guttman's improvements it now deserves a place in the top 10.

The question for you is the same as always:

What are your favourite modules?

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Comment on Favourite modules March 2004
Download Code
Re: Favourite modules March 2004
by valdez (Monsignor) on Mar 07, 2004 at 17:54 UTC
      LWP, URI, Cache::Cache, XML::Simple, HTML::TokeParser and HTML::TableExtract to interface to this site

      Have you looked at WWW::Mechanize and WWW::Mechanize::Cached? Are you doing something with your stuff that Mechanize isn't? I'm curious as to what it is, and what we can add to Mech.

      xoxo,
      Andy

      update: I think WWW::Mechanize is too powerful for my needs; I don't need an automated browser, only a way to retrieve nodes and possibly have a different cache policy for them. Does this satisfy your curiosity? :)

      That's fine. I'm just curious as to what's coming out of the parsing that you're doing that Mech wouldn't do. Also, WWW::Mechanize::Cached does all the caching for you. It uses Cache::Cache, just like you are.

      xoxo,
      Andy

Re: Favourite modules March 2004
by flyingmoose (Priest) on Mar 07, 2004 at 20:11 UTC
    Lately, for me:

    • File::Finder -- filter chaining all so much more elegant than File::Find
    • Proc::Background -- makes me able to forget the differences of process execution between Win32 and other OS's
    • File::Repl -- kind of cool non-local rsync-like module
    • DBD::Pg -- the want for it never goes away :)
    • WWW:Mechanize -- just played with it shortly, but definitely funky in a good way
    • YAML -- actual concise hand-editable serialization! Yes!
    • XML::Simple -- when folks aren't cool enough to use YAML :)
    • Tk -- looks aside, you can't beat a clean GUI API
    • MIDI::Simple -- has some fun examples, though my Computer Music for-fun projects aren't really going anywhere
    • PAR -- solid gold for program distribution. Convert perl to binary, "essentially".
Re: Favourite modules March 2004
by TVSET (Chaplain) on Mar 07, 2004 at 20:42 UTC
    • Class::DBI is currently number one in my list. It brought back the job of programming.
    • Date::Calc makes me hate current date/time system in use a little less. Sometimes I still wonder though, why not devide a year into a proper number like a 100 or 128. :)
    • Net::LDAP does not need any comment.
    • Everything else is a more or less one-time per task use, so no more names.
Re: Favourite modules March 2004
by NodeReaper (Curate) on Mar 07, 2004 at 21:34 UTC

    Reason: woolfy I'd like to see this unnecessarily insulting node deleted. This is uncalled for.

    For more information on this node visit: this

      What's the point of this post?

      It says that in the post. You seem to be unable to read, so I won't waste my time repeating it.

      My respect to everyone who doesn't post yet another inane string of uselessness in this thread.

      In both 2002 and 2003, this discussion was good for more than 35 posts. The reputations of the top level nodes are, respectively, 121 and 139. Many people have messaged me that they liked the idea, some have said so in replies.

      I'm sorry to have wasted your time. Feel free to ignore our fun. A lot of people think these lists are a good way to learn about new modules and people's tastes.

      About the respect thing: I have no respect for anyone who posts complaints anonymously.

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }


        Reason: woolfy Delete. Trollish behaviour.

        For more information on this node visit: this

Re: Favourite modules March 2004
by exussum0 (Vicar) on Mar 07, 2004 at 22:03 UTC
    SpreadSheet::Excel.. how i love AND hate thee. excel files in windows excel load up rather quickly, but it is such a bear for doing so with this terrible little module. But alas, it's so terrible, but works so well.

    While I love LWP, I wish it were named something a bit.. nicer. When someone asked me on an interview once what it was, Light Weight Process was my immediate answer. Of course, they chuckled as I was told that I did very well on their test, 'cept they meant perl's LWP. (Doh)

      While I love LWP, I wish it were named something a bit.. nicer.
      How about something like the "World-Wide Web library for Perl". Then we could shorten it to libwww-perl, or even LWP ;)

      Seriously though, those are two (three if you count both Spreadsheet::ParseExcel and Spreadsheet::WriteExcel) of my favorites - also:

      • DBI
      • DBD::Excel
      • DBD::SQLite
      Have you taken a look at Excel::Template? It simplifies the creation of Excel files, and uses the same data structure that HTML::Template uses, making Excel-ification of HTML reports quite ... simple. :-)

      ------
      We are the carpenters and bricklayers of the Information Age.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

        Well, for converting from Excel to CSV, it's simple as they give you the example. :) Can't get simpler than that.
Re: Favourite modules March 2004
by larsen (Parson) on Mar 07, 2004 at 22:26 UTC
Re: Favourite modules March 2004
by dragonchild (Archbishop) on Mar 08, 2004 at 02:26 UTC
    The enormous number of tests also made me like it a little less: it takes too long to install.

    This statement made me pause. Why are a large number of tests a "Bad Thing"(tm)? I would think that more tests would imply better code. (I am not naive enough to think it ensures better good, but if two pieces of code were in front of me and 1 passed 100 unique tests and the other 1000 unique tests, I'd be more confident initially with the latter ...)

    Plus, don't you install each distribution only once in a while?

    ------
    We are the carpenters and bricklayers of the Information Age.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      Why are a large number of tests a "Bad Thing"(tm)?

      They become a bad thing when you have 157732 tests for 2245 lines of code. That is 70 tests per line of code, while of course a lot of lines don't even contain any logic. make test for Regexp::Common takes too long. I've already met a sysadmin who refused to install it because of that and I'm slowly becoming one myself.

      if two pieces of code were in front of me and 1 passed 100 unique tests and the other 1000 unique tests, I'd be more confident initially with the latter

      Of course, but do you really need thousands of tests for zipcodes? Are these thirty six thousand tests really needed for a palindrome regex?

      Plus, don't you install each distribution only once in a while?

      Yes, but I dislike this test suite that takes minutes to run for the same reason I dislike compiling from source. I am lazy and impatient and that is exactly why I like Perl.

      There's only one thing regarding testing that I dislike more than an exaggerated test suite like Regexp::Common's and that is not having tests at all. I think R::C could do with only, say, a tenth or maybe a hundredth of its current test suite. For development, a huger one might be nice, but 1.5e5 tests on installation is more than I'd like.

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

        I'm still confused. What's wrong with kicking off an installation and going to get a cigarette or a cup of coffee? Kick it off, then go to lunch. Or, kick it off at home and go watch the latest SG-1 episode ... That's what I do when I'm installing OSes or Apache, and those take over an hour each. *shrugs* I guess that it seems a little too impatient, in my book.

        And, frankly, I don't think that thousands of tests for regexes is ridiculous. It's extremely easy to get them every-so-slightly wrong. Abigail-II is right, imho, to provide that kind of coverage. Those regexes are going to be depended on for business decisions. It might be a small part, but it's nice to know that "It Will Just Work".

        And, the test suite on installation isn't always just for installation. I've played with making changes to many modules. I use their test suite for making sure my changes are backwards-compatible.

        Now, maybe it might be useful for "make test" to have a "make test TEST_TYPE=dev" vs. "make test TEST_TYPE=install" (which would be the default). Then, the tester would indicate a subset of tests which are regression-only and which ones should always run.

        Plus, you can install the distribution without running the test suite ...

        ------
        We are the carpenters and bricklayers of the Information Age.

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

        Hmm, I just installed it and it only took about 60-90 seconds or so. That's not a big problem AFAIC.
      Plus, don't you install each distribution only once in a while?

      Define "once in a while". I install CPAN modules less often than I use them, but I don't very often go a week without installing some modules off of CPAN onto one or more of the various computers that I use or administer at home or at work. Long install times are annoying, annoying enough that I have developed this little habbit of doing screen -R CPAN, starting the install, detaching, and doing something else for a while. But I can't continue to work on whatever I was doing until the install finishes. I wish more of the modules on CPAN were pure Perl so they wouldn't take so long to install. It is my sincere hope that in Perl6 XS will be unnecessary and heavily deprecated.


      ;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print
Re: Favourite modules March 2004
by toma (Vicar) on Mar 08, 2004 at 02:27 UTC
      File::Slurp and File::Flat? File::Flat has a slurp method, but neither it nor File::Slurp's use binmode (on purpose -- dumb).
Re: Favourite modules March 2004
by greenFox (Vicar) on Mar 08, 2004 at 04:09 UTC
      Why in CORE? Besides, module is broken.

        Because I use perl on a large number and variety of machines where installing modules is not always practical or possible, if it is in core I don't have to worry.

        I understand there are moves afoot to "slim down" core and I don't object to that but personally I think both of the modules I mentioned are small and useful enough to warrant including them... not that I expect my opinion to carry any weight :)

        --
        Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho

      I'd like to see [slurp] added to the core
      Then take a look at Perl6::Slurp for a Perl 5 implementation of our current notion of Perl 6's slurp built-in.

      What? You meant "added to the Perl 5 core"? Sorry, can't help there... ;-)

Re: Favourite modules March 2004
by PodMaster (Abbot) on Mar 08, 2004 at 07:15 UTC
    I use lot of modules {and I like a lot of those I use}, but favorite status is very hard to achieve, which is why I only have a single favorite this time {I am excited}: Test::Pod::Coverage.

    These I like, they're kind of new (some just to me)(:

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

Re: Favourite modules March 2004
by castaway (Parson) on Mar 08, 2004 at 09:47 UTC
    Favourite/Most used modules currently:
    (no particular order)

    Used but not much re-used:

    New kids on the block:

    Looked cool but failed to install itself+dependencies:
    CPANPLUS

    Module list courtesy of: perl -MExtUtils::Installed -le'print join("\n", ExtUtils::Installed->new->modules)' (only been using this machine since December)

    im2 uses a whole bunch daily, including 5 date/time modules, damn I wish there was one that "did it all".

    C.

      I don't have a Top 10 List prepared, but I've been playing with File::Scan lately. I primarily use Linux - but when people send me viruses I like to see if this module can catch it. Most times it does, or at least labels them as "suspicious".
Re: Favourite modules March 2004
by lestrrat (Deacon) on Mar 08, 2004 at 12:17 UTC
Re: Favourite modules March 2004
by jonadab (Parson) on Mar 08, 2004 at 23:23 UTC

    Here's the short list of modules I don't like to be caught without. These are the ones that I don't just find convenient from time to time but rely on constantly.

    • CPAN. Perl isn't properly installed until this is set up, as far as I'm concerned.
    • DateTime (I might die without this one.) Also certain DateTime::Format modules to go with it.
    • DBI and one of the DBD modules. (I've been using DBD::mysql, but one of the others will probably do just as well. You want the corresponding DateTime::Format module, e.g., DateTime::Format::MySQL, to go with it.) I also have my own little wrapper module with functions for my most common queries (add (takes a table name and a hashref), update (ditto), and so on), but if I need to do something I don't have a function for I can always hand-build a query on the db handle.
    • WWW::Mechanize saves a lot of time. If you do a lot of this, you might also want HTML::Tree as a companion. The look_down method is pretty keen.
    • Archive::Zip is spectacularly useful, especially for dealing with OpenOffice documents. (Next question: will I eventually pick an XML module similar to HTML::Tree and use that in conjunction with Archive::Zip for parsing, modifying, and saving my documents? So far I'm still dealing with the XML by hand...)
    • Data::Dumper is a really useful debugging aid. There's also Data::Dumper::Streamer
    • Clone::PP is helpful. The most common things I clone are DateTime objects.
    • Finally, I have a handful of my own include files that I wouldn't want to be without; I copy them to every system I use Perl on. These aren't modules per se, as I 'require' rather than 'use' them.

    ;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print

      Clone::PP is helpful. The most common things I clone are DateTime objects.

      But DateTime has a clone() method! Why not use that?

        But DateTime has a clone() method! Why not use that?

        Oh, so it does. Cool. Well, mark that as one less use for Clone::PP from now on (though of course it'll still be useful for other stuff) :-)


        ;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print
Re: Favourite modules March 2004
by coldhawk (Monk) on Mar 09, 2004 at 13:50 UTC
    I don't currently use that many modules, because i fancy security and many modules that i would needed for this and that weren't that secure, and most cases just as lazy person i am, i wrote the whole code part myself. only in last resource i start fixing or changing thigs to way i like them on ready made modules, when i can't find or there isn't enough time/lazyness to start learning that. but what i have just browsed i have noticed there are lot of good modules out there, but i just haven't got time to start checking them out.

    here are currently what i have used for this/last year often.

    CGI = only used it for multipart forms, until i got some time to read more about their used format.
    Digest::MD5 # always for passwords.
    File::Copy # just to keep me from doing it without copy/unlink style.

Re: Favourite modules March 2004
by tsee (Curate) on Mar 10, 2004 at 17:57 UTC
    The modules I use most in my stand-alone scripts are: (list was generated by a script, strict and friends removed)
    • Data::Dumper
    • Pod::Usage
    • File::Find
    • Imager or GD (using Imager exclusively now)
    • Parse::RecDescent (for fancy input parsing)
    • Getopt::Long
    • DBI
    • DB_File (for hash-persistance)
    • Config::IniFiles
    • CGI
    • HTML::Template
    • File::Stream
    • Tie::Hash::Abbrev (for shell like interfaces)
    • File::Copy
    In my modules (http://search.cpan.org/~smueller), I tend to require other modules: (hand-selected list)
    • Carp
    • Data::Dumper
    • Test::More, Test::Distribution (staring to use this), Pod::Coverage
    • Parse::RecDescent
    • Imager, GD
    • many modules in the Math::* section since I'm developing Math::* modules myself pretty actively. Examples: Math::Complex, Math::Approx, Math::Spline, Math::Big*, Math::MatrixReal, etc.
    • perltidy (or Perl::Tidy), well, at least indirectly.
    • and many more...

    Steffen

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://334621]
Approved by kutsu
Front-paged by grinder
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (13)
As of 2014-09-22 09:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (185 votes), past polls