tags:

views:

564

answers:

14

I am a Perl developer and have gravitated towards a specific suite of modules that I use for almost everything. I primarily build GIS and database oriented web applications for reporting and data entry and the like.

I'm curious what groups of modules other Perl devs have settled on using regularly.

Mine:

  • CGI
  • DBI
  • Spreadsheet::WriteExcel
  • Spreadsheet::ParseExcel
  • HTML::Template
  • Text::Template
  • PDF::Template
  • PDF::API2
  • Geo::Shapefile
  • LWP::Simple
  • XML::Simple
+2  A: 

I use DBIx::Simple instead of plain DBI, the interface is, well, simpler and more regular. Also, of course, XML::Twig for XML processing. Then Getopt::Std for (simple) options, and YAML::Syck for temporary storage that doesn't require a DB, as well as debugging, instead of Data::Dumper. And, like you, Text::Template for most complex output.

mirod
Hmmm. DBIx::Simple looks cool. I did not like DBIx::Class at all. I am rarely parsing large XML, which is why I use XML::Simple, though Twig is a very good extension.I've never even heard of YAML::Syck, but I suppose that's why I asked the question!
Frakkle
YAML::Syck is one of the (numerous!) YAML modules. YAML is a convenient way to dump (and retrieve) Perl data, wheteher it's scalars, hash refs, array refs or objects. It's language-neutral and human-readable.
mirod
+3  A: 

I haven't used Perl in a while (sorry, my employer uses a mix of Java and C#), but I recall using the following quite a bit (in alphabetical order):

(You might notice a focus on non-framework webapp modules in there...)

R. Bemrose
Ah yeah, I forgot to mention CGI::Session.I admit, I like to pass all the crypto-stuff on to the database.
Frakkle
Do not fear the CGI::Application!
MkV
+3  A: 

My most common modules are probably

I'm not sure if it counts as a "tool" or not, but I tend to write my programs in a mostly functional style. I try to only assign to each variable once, and I try to avoid subroutines that modify their arguments. I generally prefer "grep" or "map" over a loop. The biggest exception to this rule is when I am building up a return value. I may push things onto the end of an array or add items to a hash in a loop.

Glomek
+1 grep() and map() are awesome.
Chris Lutz
+13  A: 

Checking over recent stuff, here's what I see most often:

  • Getopt::Long and Pod::Usage make options and man pages a breeze
  • File::Find because I finally get it, and as much as I want to use File::Find::Rule instead, I keep forgetting
  • Data::Dumper - aka, the best debugger you never knew you already had
  • Carp to figure out what else I did wrong
  • Storable for when a proper database is just too much
  • POSIX but almost only ever for strftime
  • App::Ack - I almost forgot it because I use it constantly, but not so much in Perl as instead of Grep on the command line.
Telemachus
The POSIX comment made me laugh! I try to use DateTime when I remember, but I must admit that all too often I simply use strftime. DateTime->from_epoch->subtract( months => 1)->ymd is very convenient though.
mirod
ack is one of my favorite new tools.
gpojd
Can I propose s/Data::Dumper/Data::Dump/? It's Data::Dumper done right.
j_random_hacker
I almost automatically type "use POSIX qw<mktime strftime>;" for POSIX. There are times when I would type one, but I'd end up using the other before too long.
Axeman
+7  A: 

Here are three good sources to look at:

Anirvan
Not bad to have lists, though I'm more interested in what individuals throw into their own black cauldrons.
Frakkle
+7  A: 

Off the top of my head:

I'm probably missing some obvious ones.

gpojd
+5  A: 
kixx
+2  A: 

Not counting all the module development and test toolchain stuff, my toolbox for getting work done has included:

Nuts and bolts:

Hand tools:

Power tools:

xdg
+1  A: 

I'm surprised nobody has mentioned Data::Dumper, I tend to leave the use declaration in my scripts because I know it will be useful for maintenance debugging.

andymurd
+1  A: 

I have used these each quite often, many of them going back 10 years.

CPAN module is, of course, one of the best that we sometimes forget about because it fades into the background. It is a meta-module, so to speak.

Top group below appears in output of our newperl script which provides a working example of best practices. the resulting perl script implements some basic requirements and hints at basic debug, so that perl novices can develop good habits using a real-life design. we have an analogous newperlmod as well.

The first two are more like pragmas in that they really hook onto the nature of the language built-ins.

Data gathering toolbox -- more specialized

A recent discovery that is a boon for maintenance. Useful for output of config and batch files, e.g.

popcnt
+1  A: 

Net::FTP. Much of my job involves pulling files off of one system, manipulating them, and pushing them onto another system.

peejaybee
A: 
  • Perl6::Attributes
  • Regexp::Common
  • DBI
  • Data::Dumper
  • Getopt::Long
  • FileHandle
  • Tk
  • Tcl
  • Tkx
  • GD
  • Config::Std
  • Inline

Without Perl6, the first one on the above list makes modules infinitely more readable (IMHO).

xcramps
A: 
  • CGI::Application::Dispatch (thus CGI::Application too)
  • CGI::Fast
  • DBIx::Class
  • Template Toolkit
  • DBD::Pg
  • Coro
  • AnyEvent::*
  • Gtk2::*
  • Config::General
  • PDL
  • Devel::NYTProf
  • Moose (wish it was faster to start up)

I develop web apps and desktop apps with these.

I notice a lot of plain CGI.pm fans on here, though I like CGI::Application, especially combined with C::A::D, a lot. It's still pretty light-weight, has a reasonable amount of plugins, a decent website and isn't as slow or heavy as Catalyst.

MkV