It saddens me too.

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.