It also saddens me that large parts of the community are still in denial
about the downwards trend. Yes, I know that the TIOBE methodology sucks (I've
said so myself), but business people still make decisions based on those
numbers.

Moreover there are other, less contestable comparative metrics by which Perl is
losing, like module count and
job
counts (yes, that's from 2008, I know; but newer comparisons I've seen but
don't remember the URLs of right now mostly confirm the trend). Also,
github has
numbers that place Perl at no. 12, which is disturbingly close to what TIOBE
says.

Some people use the argument that goes like this: those comparisons are
relative, and the programming language "game" is not zero-sum. The total
number of programmers is increasing, so even if Perl is losing in terms of
relative numbers, it is (or might be) gaining in terms of total numbers. That
argument is somewhat correct (and again, I've used it myself in the past), but
I still think that it is a rather weak argument for defending the status
quo.

Maybe I'm hanging out with the wrong Perl 5 people, but many parts of the Perl
5 community don't feel all that vibrant, and when I try to answer a Perl
question with code that is far from best practises, I try to search for a
tutorial that explains how to do it better (use strict; use warnings; use DBI
placeholders; use lexical file handles etc.) and most of the results that come
up are crap (outdated, or don't get the essential points across). Finding Perl
programmers for $work is very hard, and so on.

Even if you ("you" meaning the casual reader, not the OP here) are not
convinced, please ask yourself one question: If we want to improve things,
what's the best starting point? Admitting that there might be a problem, or
insisting that everything is fine?

Assuming for a moment that you are with me, and not with the denial camp,
the next step is asking "why?".

I think there are several reasons. One is that Perl isn't new and shiny
anymore. Sadly there's not much we can change here.

Another reason is that there has been a lack of killer applications written
in Perl in the past year, or people simply don't talk about that stuff is
written in Perl. I have hopes that http://www.builtinperl.com/ changes the
publicity situation a bit for the better, and personally I'm excited about
Duck Duck Go and the
Lacuna Expanse.

But there is a very important reason that is easy to overlook if, like me,
you love Perl: There are parts of the language that are plain crap. Not having
subroutine signatures is plainly embarrassing. Having to bless objects
yourself is embarrassing. The fact that say reverse 'foo' doesn't
reverse the string (even though reverse is the recommended way to
reverse a string) is just wrong. There are lots of other WTFs in the language
that I won't go into; that's a topic for a different Meditation, if there is
sufficient interest. But any experienced Perl programmer has come across a lot
of them.

Perl people often react with denial to these problems as well. The standard
response is "But we have Moose" or $WhateverCoolModule. Well, Modules
are a great tool for tasks like speaking HTTP, but to be an accepted patch for
a missing language feature, it needs to be very widely adopted. Moose
probably comes closest to that in the OO world, but when you take a look at
the three big web frameworks, you'll see that only Catalyst uses it
(and some of the core contributors regret it), Dancer doesn't, and
Mojolicious uses its own OO implementation.

The situation is even worse in the realm of subroutine signatures; there's
a myriad of modules out there, most of them using source filters (and yes,
Devel::Declare still shares the downsides of source filters),
most of them force you to write a different keyword than sub (which
trips up any static analyzers, linters etc.) and none of them seems to be a
clear winner.

So, we need evolution and/or revolution. In the core, not just in modules.
Since I invest my free time in revolution, it is not my
place to comment on how evolution should be done. I just observe that it's
vital.

All other efforts depend on that, in the end; writing good tutorials
depends on having a consistent, understandable thing to explain. Having fun
using the language depends on not having to re-implement OO (or relearning the
currently hip OO module), and so on.

And all efforts depend on admitting that there's something wrong in the
first place. Thank you, starX, for brining up the topic, even if it's an
unpleasant one.