mod_perl2 is really difficult to beat if you need to dig into the guts of Apache. DBIx::Class is a huge win if you need/want an ORM but you've been given a really weird pre-existing DB schema. POE has been around forever, and makes really stable long running daemons that don't have to be babied. CPAN has stupid amount of tools for automating sysadmin tasks, all of which you'll probably end up using once, putting in a cronjob somewhere and forgetting about because it will just work. Any time you need to deal with something old, or weird, or both there's probably a CPAN module for that, you can find it via search, and it probably has tests and docs. Template Toolkit for creating uglyass text is both nice to use and full featured (if you don't want to go down the XSLT hole). I've also found that Perl handles I18N, unicode and uglier things (like shift-jis) fairly well. Almost every payment processor has a module, and they all have a standard(ish) API, so they're mostly interchangeable. Likewise crypto stuff is fairly standardized and pretty complete. In general, if you have to tie something to something else that's weird, Perl is a good bet (because someone has probably done it, put it on CPAN, and documented it).

That's a few of the problems I think it stands out as a great tool for.

mod_perl2 is a brilliant tool for writing apache modules.

Catalyst is a far better web framework. So's HTTP::Engine.

And with the PSGI standard and Plack reference implementation, the lighter weight stuff is starting to standardise too - my new toy, Web::Simple, leverages Plack to provide Catalyst::Engine-like functionality but in a very lightweight manner and very shareable between different frameworks with different philosophies.

I remember showing DBIx::Class to Simon Willison at a LugRadio Live - he looked at some of the complex queries chained resultsets and easily build and his jaw dropped. We were going to try and get round to me helping him fix Django's ORM to have more of the capabilities of DBIx::Class in return for him helping me build a django-admin-interface-like piece of code for Catalyst but we never quite got to it, sadly. Happily, our respective communities seem to have already done similar things without us :)

I Absolutely agree with regards to web frameworks. But there's a time and a place for apache modules, and mod_perl is definitely the tool for that job.

My general rule of thumb is:

Perl5+MooseX::Declare+lots of CPAN for general purpose programming (web apps, network daemons, automation code)

Old school scripting style Perl5 for when shell gets clumsy

Shell for simple scripting

C for bit twiddling either due to hardware level madness or for performance

whichever lisp REPL I have handy for reasoning about high level logic

I don't write GUI apps so I have absolutely no idea what I'd use for that if I did. Probably ObjC on OS X and Perl5 for cross platform (easier to learn Wxperl than to do without CPAN when I'm not aiming for mac-quality polish, I suspect, though that could easily be familiarity bias on my part).

And ... that doesn't really say what Perl5 is best for - it says what I choose to use it for - my general purpose mid range programming language in one configuration, and my primary scripting tool in another.

I actually quite like python (and I hear wonderful things about their wx libs so I'd definitely look before starting on a GUI app) but I like being able to extend my language up towards the problem lisp-style and it doesn't want to let me do that to the same extent as Perl5.

I don't mind ruby but their decision to inflict the single-inheritance smalltalk object model on me rather than the more flexible approached both Perl5 and python allow leads me to discount it for any project where I know I'm going to be heavily object oriented - if I wanted bondage and discipline in my OO I'd be looking at statically typed languages instead.

I'm not sure any of the above really answers your question, but hopefully it explains to you why I don't have a better answer at least :)

I think I have too much to say about this for a HN comment, but I will try to condense.

Perl is okay for parsers; but I think other languages have better parsing libraries and other languages run faster. I tend to prefer Haskell these days. It runs quickly, it has good libraries, and it's easy to get it right. (Most of the stuff I have been paid to write is Perl, though. It does get the job done, and it's certainly easier to get right than C or C++.)

Where I think Perl is really really great, though, is for building large applications. Applications are often a lot of pieces that need to be glued together, and this is were being a "glue language" really shines. The "language", of course, is CPAN. There is a library that gives you a good abstraction over almost any task you would ever need to perform.

If you are writing a large application, you don't want to have to implement boring things like HTTP header parsers or HTML templating engines. You want to write your application. Perl lets you do this to whatever extent you like; you can have libraries that make all the choices for you, or you can write everything yourself. (Most people choose some combination of this.) The language itself is fine for this, and the libraries support it. (One time, I wrote a web application without a web framework -- but I used many parts of other web frameworks from the CPAN. So even though I was writing something fairly obvious from scratch; I could still use libraries for the parts I didn't really care about doing My Way.)

I know people are going to say, "well, my language has a library for xxx", but they are kind of missing the point. CPAN has really good libraries for popular tasks, and At Least Has Something for relatively unpopular tasks. But it also has libraries for things other than "tasks"; you can change Perl itself with libraries, and there are libraries for very small programming problems. (Things that you probably wouldn't think you need a library for, like finding the largest element of a list.)

It is just hard to explain this to people that haven't used Perl. They think the only library they will ever need is Ruby on Rails, but there is so much more to library use than huge frameworks.

Anyway...

Perl also makes metaprogramming very easy. This means I can quickly implement some abstraction that's higher-level than "raw Perl", and then implement my application in terms of that abstraction. This makes the application code easier to read and understand, and it makes the application easier to write. As I hinted at above, there are a lot of libraries for this; so metaprogramming isn't some magical thing that only wizards can do -- it's something accessible to every user of the language that can imagine an abstraction.

My blog is currently dead (due to my general disinterest in system administration)... but I wrote a long article a few weeks ago about the sorts of abstractions that the Moose object system lets you build. If you care to read it, I think it's still on the planet.perl.org main page. Search for my name :)

I love CGI, DBI. I can write my own SQL. I don't need an ORM. What modules do you suggest for developing web apps using Perl. Mason or Template Tool kit or something else.

I have to vote this blog post up so I have a reference back. :-)