• strict
• warnings
• CPAN
• Carp
• DBI

There are also many useful modules that don't really have a learning curve; you just look at their docs once or twice, and then you can use it to great benefit.

I agree with the last bit - there are lots of modules that have one or two useful methods that one can just use intuitively. LWP::Simple comes to mind - it's not the most flexible or robust way of implementing a web client, but it takes seconds to get the hang of it and it's good enough for many situations.

One of the first modules I got to grips with was CGI, and I shudder to think how much time I'd wasted before that doing things by hand that it would have let me do automatically.

You only needed to look at the DBI docs once? Wow... Do I need "fetch," "fetchrow," "fetchrow_array," "fetchrow_arrayref," or something else? It's a useful module, but unless you use it constantly, I can't imagine using it without the docs.

Read my node again.

I wrote

There are also many useful modules that don't really have a learning curve

I never said that DBI was one of those without a learning curve. (Unless my English is worse than I thought, and I wrote something that I didn't intend).

That depends a whole lot on what you intend to use Perl for. Nice thing about CPAN is that there are really good modules for most things you might want to do.

If you don't have a nice IDE and don't feel inclined to learn to use the debugger then Data::Dump::Streamer or Data::Dumper are good friends.

GetOpt::Long can save a bunch of time if you are writing command line based scripts and Tk is pretty good for quick and dirty GUI based stuff.

A quick trawl through a bunch of my scripts shows a pretty high hit rate for File::Find, Mime::Lite, Date::Manip, List::Util and a whole bunch more. I guess really, being able to use CPAN is the place where it's worth investing your initial time.

Just went to install 'Mime::Lite'... and discovered it's actually MIME::Lite.

---

email: perl -e 'print reverse map { chr( ord($_)-1 ) } split //, "\x0bufo/hojsfufqAofc";'
'Under no circumstances should you program the way I say to because I say to; program the way you think expresses best what you're trying to accomplish in the program. And do so consistently and ruthlessly.' --Rob Pike

Every script and module uses these (included in my template for new files):

• strict
• warnings

Also in my template, which I later comment out when things stabilize:

• diagnostics
• Data::Dumper

User interface:

• Getopt::Long
• Pod::Usage
• Carp

Very handy:

• List::Util
• List::MoreUtils
• File::Basename
• File::Find::Rule
• Text::Table

Great for understanding (others') regular expressions:

• YAPE::Regex::Explain

If you have the need for XML parsing:

• XML::Twig

Noone seemed to mention CGI::Application and HTML::Template.

(This is mostly directed to the OP.)

I think CGI::Application is a great thing to have but I also find it over-recommended. It's how, IMO, most solid web hackers would solve the problem of a big dispatch table with hook points. It's a good way to normalize flow and share plugins and such but if you're going to get your web code organized anyway, go all the way to Catalyst. CGI::Application is either a lot of effort that won't get you over that last hump (the many cool things Cat can do) or it's not much effort that is basically repeating things you already know and understand.

I hope that came out right. It's in the context of the OP: return on effort. I'm not criticizing CGI::App. I think it's a valuable package. I just think it's either on the easy side if you already know CGI programming well or less return on the effort than Cat if you'll need to learn a bunch either way.

As for HTML::Template, I completely understand the purists who opt for it because it's probably the theoretically cleanest View of those available. I personally would never choose it over Template::Toolkit. And that's another effort to gain ratio. HTML::Template is a snap to use. TT2 is a mini-language so it's a lot of effort. It's been worth it to me.

One of the ways you can tell if a more difficult package (or programming language for that matter) is worth the effort is to look at the community. TT2 and Cat and DBIC have active communities where answers are readily available on IRC, mailing lists, wiki, blog posts, or here at PM. If a package isn't worth the trouble, it won't be able to attract and retain a dedicated base.

I agree with moritz that there are many that require very little effort and pay handsomely. I interpret your question to also mean, what requires a lot of effort but ends up worth it in the end. These are pretty web centric but I recommend XML::LibXML, HTTP::Request, Catalyst, and any RFC/Standards based modules like URI or JSON. Modules like these, the latter or HTTP::Request (and HTTP::Response) especially, have the wonderful side-effect of teaching you how the underlying standards and technologies work. When you pick those up you're also picking up loads of extra knowledge which will transfer to other areas of work and even other languages.

You interpret correctly. Thanks for sharing the web-centric ones... that's exactly the sort of reply I was after. :)

---

email: perl -e 'print reverse map { chr( ord($_)-1 ) } split //, "\x0bufo/hojsfufqAofc";'

I'm lame and undercaffeinated. I left out DBIx::Class and Rose::DB even though I was thinking about them when I started typing. Each of those has a bit of curve, especially when setting things up the first time or two. They repay in spades once any bunch of code or data starts to grow or get hairy or develop special needs.

Because of the complete and coherent way it provides you with a standard approach to do OO in Perl.

Because of the way it provides a declarative syntax to accomplish a lot of the things you need to do in order to produce solid code. For instance: Read-write/read-only values. Flexible type constraints where it makes sense to you. Required and default values. Lazy initialization. These are things you perhaps wouldn't normally bother with because of the extra effort and lines of code it would cost. But now all that is much cheaper.

Because of the way it scales from the very simple and minimal solutions, all the way up to meta programming.

Because of the way it is establishing itself as the foundation of bigger frameworks, e.g. DBIx::Class and Catalyst. This means you may very well need to know the basics of Moose anyway.

/J

Well, you sold me. It's been great learning which modules are going to reward my efforts, but all the buzz I've been hearing about Moose suddenly makes sense. ++.

---

email: perl -e 'print reverse map { chr( ord($_)-1 ) } split //, "\x0bufo/hojsfufqAofc";'

The modules I find give me the biggest bang-for-buck are the ones that allow me to avoid learning other, more costly methods of doing the same thing. strict is an obvious example of this, it tells me up-front when I've made a typo in a variable name, rather than me going through a costly debugging process.

In this regard, Moose is a big win, as it means I don't have to learn Perl's somewhat esoteric OO system

The other big bang-for-buck modules for me personally are ones that I've written myself, and which I find myself using in practically every program. IPC::System::Simple means I never have to look at $? again, or find myself wishing Perl would allow backticks without invoking the shell, or wishing that system() really did work the same way on all systems.

All my code these days start with use autodie. Having to write or die... after a call to open, close, chdir, unlink, binmode, rename, mkdir, rmdir, fork, etc etc is a total waste of time for me. Using autodie means not only does leaving out the manual error handling becomes correct, but I end up with nicer looking errors, and a number of esoteric bugs go away (eg, calls to fork and open which can legitimately return zero for success, and undef for failure).

When I move from wanting my program to simply die on error to something more complex to recover from that error, autodie gives me sane upgrade path, since the exceptions it produces contain full information as to which call failed, its argument, location, errno, and other pertinent information.

Since I've just turned this post into a massive advertisement for autodie, I should link to an old video on its usage. The big changes is that autodie now works in 5.8.x (not just 5.10.x), and the exception interface has changed slightly since the beta.

Since no one has mentioned it: DateTime is another great example. I resisted using it at all for a long time. It has big dependencies. It's difficult to understand its components. It has many moving parts. Date::Calc and Date::Manip are so easy by comparison. But in the end, date stuff is so messy, and weird and complicated that the seemingly difficult and scattered pieces of DateTime start to reveal themselves as necessary, clean, and flexible.

If I just want something like Date::Calc::check_date, great, but now if I have any plans to do anything more I reach for DateTime. My reticence kept me away from it for too long; it was false economy.

A few above have recommended just waiting till you need something to use it. I disagree. What happens when you wait till you need it is you don't even know what you need. It's like Turing machines. Any given package for a problem domain can do the work in front of you. You have to know them to know which you want. If you wait till the last minute to find out that DateTime or DBIC or Cat is the solution you want, you just let your deadline slip; maybe by a couple of weeks.

(update: jplindstrom was typing while I was so I didn't get the chance to say I agree completely, especially about skipping the mistakes -- packages with big, or expert, user bases tend to turn over bugs much more effectively.)

I wouldn't try 'web stuff' without CGI; CGI::FormBuilder is also worth getting the hang of IMHO.

HTML::Template and Template::Toolkit can also be useful. I have actually used HTML::Template as job control for IDL

Can't comment on much else because I don't have huge experience

The original question wasn't purely about 'web stuff', though I appreciated Your Mother covering that area. I'm actually interested in the most worthwhile modules for any problem domain... parsing, visualization, natural language processing, biology, whatever.

---

email: perl -e 'print reverse map { chr( ord($_)-1 ) } split //, "\x0bufo/hojsfufqAofc";'

Got to haves:

Moose

MooseX::Traits

YAML

XXX

Devel::SimpleTrace

Module::Install

Module::Starter

Extraction:

Text::CSV (the new and improved, for all ___ deliminited files)

DataExtract::FixedWidth (I created it, but it is still probably one of my most used modules)

HTML::TreeBuilder

Content Creation:

Catalyst

Template

For me the most important thing isn't knowing how a certain module works, but knowing where to find one or more modules that do what I want :)

• General. This means a technical domain which is usable across many business domains.

• Complicated and big. This means e.g. implementations of protocols and languages (programming and markup).

By learning to use these modules you both learn a bit of the domain, and you don't get to make the (sometimes fatal) mistakes on your own.

Domains matching the points above are: databases, network interaction (Internet/Web), date/time, Unicode, XML.

/J

Log::Log4perl is worth the learning curve, as is perldebtut (though not really a module).

I think that's overstated (to put it lightly). There are lots of modules that require domain-specific knowledge - the ones from Bioperl, for instance.

---

email: perl -e 'print reverse map { chr( ord($_)-1 ) } split //, "\x0bufo/hojsfufqAofc";'

The modules don't define your domain, or teach you about it, they just do X using N techniques (OO, callbacks, iterators ...). Which domain for highest return of time/energy/X? Golf :)