Reliable and performant multi-threading applications,
like advanced graphic-intensive GUIs, are probably the most visible problem for Perl right now.
Any operating-level code is out, too, since Perl is based
on C, and the standard C library functions are in general
not reentrant. That probably also eliminates Perl for a lot of
embedded device code.
Another, more disturbing problem for me is that, IMHO, it
is very hard to develop with large teams in Perl,
since there is no means to express the interface of a function in code. You have to rely on POD to document your interfaces. This makes it very hard to check programs for
interface consistency. Also, the variety of parameter passing idioms ("my $arg = shift;", "my ($arg) = @_;", "my %named_args = @_;", "my ($fixed_arg, $ref_to_hash_of_options) = @_;", "my ($fixed_arg, %hash_of_options) = @_;", etc.) in Perl makes for a nice array of hard-to-find bugs when combined with lack of documentation.
That said, for small teams or single persons Perl is *the* most
productive language I have seen till now. This is largely because of the amazing CPAN. Says Bruce Eckel (in: Thinking in C++. Prentice Hall, 1995. Translated from my German version.): "The only possibility of achieving really impressive increases in productivity is using other people's libraries."
Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com