True on the sales point. And it's getting harder and harder to find coders who want to spend all their time writing perl, as great as it is. That makes it tough for enterprises to maintain perl codebases.

Also, more CPAN libraries seem to be in a state of atrophy these days and I think the long-looming specter of perl 6 has had a depressing effect on that community.

The post talks about Moose, which is a behemoth with huge and varied dependencies and must be be tougher to maintain these days. Every time I've tried to write a project in Moose, I've regretted it in the long run.

However, I've written plenty of big, enterprise-class projects in perl instead of buying them from major vendors. Over the years, we were almost always able to beat the value proposition of Big Software precisely because we had a solid team of perl coders.

The spectre of perl6 stopped bothering us about 2006; CPAN uploads have been up every year since.

If you find Moose too many dependencies, try Moo.

Don't underestimate the effect that the Perl 6 disaster has had on the reputation of Perl as a whole, even if Perl 6 is a rather different language in many ways, and generally promoted by a separate community.

Even if the Perl 5 community has generally admitted that Perl 6 was a failure and has moved on, a lot of people first think about how disastrous Perl 6 was well before they think about anything positive involving Perl 5.

> The spectre of perl6 stopped bothering us about 2006

From a practical usage standpoint, sure. But wouldn't you agree that an effective major version freeze has had a chilling effect on the progression of the language?

I'd argue it's had a deleterious effect to varying degrees, even since 2006. It's not enough for a community to be not bothered. They need to be energized, and it's tough to make the argument that the perl6 snafu has been helpful to the perl movement.

> CPAN uploads have been up every year since.

CPAN traffic was down over 10% last year, according to Alexa. In fact, many perl popularity metrics were down at least 10% in 2013. [0]

My experience, admittedly anecdotal, is that CPAN packages in general are not maintained with the same vigor as in years past. But why would they be, if people are moving their focus to other languages?

Regarding Moo, thanks - I'll definitely have a look.

[0] http://szabgab.com/the-popularity-of-perl-in-2013.html

> They need to be energized

2006 is when the energy around perl5 / new wave of cpan development became palpable to me.

Have a look at Task::Kensho - you'll find a fair chunk of the stuff mentioned in there originates from 2006-2009 or so (and has been actively developed since).

> My experience, admittedly anecdotal, is that CPAN packages in general are not maintained with the same vigor as in years past. But why would they be, if people are moving their focus to other languages?

That or the CPAN packages you've been using have been superceded but you've not found the replacement.

We're fairly terrible as a community at communicating when that happens.

If the OS is Windows, as it often is in these environments, C# seems to strike the best balance between safety, ease of recruitment, and flexibility. I have not used it in several years, but I still look back and miss awesome elements of the language like linq, the selection of super polished UI frameworks, Visual Studio, the ability to use dynamics when you needed to, the lack of drama in the community, and the ease of finding answers to obscure questions on SO. Of course, I left the platform for a lot of the same reasons, but in the context of being increasingly involved with OSS. That said, the positives still hold true for the enterprise space you are describing.

> Granted that it's not as dense as Perl, but it's also type-safe and with good conventions, readable.

The argument for Java is that there is a wide developer base, and lots of libraries. Perl, with appropriate frameworks, can be remarkably typesafe too (see Moose, etc). It's still loosely typed under the surface, but you have good error handling of invalid type syntaxes as long as you don't break encapsulation.

The big things I am looking at though are:

1. Maintenance and testing.

2. Readability

You can write unreadable crap in any language. What Perl excels at is allowing you to improve readability and maintenance/testing by building mini-dsl's in your framework which reduce testing footprints.

It's really hard to write unreadable crap in Java. Even if you do, there's automated refactoring to fix it. That's the thing about Java. It makes it really hard for clever bad programmers to do a lot of damage to a project. With Perl the sky's the limit.

>>It's really hard to write unreadable crap in Java.

I work on legacy Java code bases every day, where I see thousands of lines of code all to just simply set and read variables.

I'm not sure how that's even remotely described as readable.

It's readable and easily followed spaghetti code it just obscures what the programs means with unnecessary details.

People say the same about Python, but it is completely possible. Deeply nested hashes with no comments explaining the structure. Variable names such as 'Indexes' and 'indexes' in the same function. I have had to rewrite code like that.

As long as function and variable names are arbitrary, you can write code that appears to do one thing and does something else. Far more damage can be done that way than by straight obfuscation.