Perl provides many, many different ways to achieve the same thing. This is somewhat by design, in the idea that Perl should match your own intuitive style. But most people's styles are not yours, and it becomes impenetrable.
IMHO Ruby's strength over Perl is the much stronger OO, Python's strength is the focus on "there is only one way to do it", which lets most people be able to grok most of your code.
I couldn't go back to Perl by choice now. I first jumped to Python just to get some sense of clarity in my life, but now I prefer Ruby due to how its extreme openness means there are some really awesome gems out there.
> Python's strength is the focus on "there is only one way
> to do it", which lets most people be able to grok most of
> your code.
It's a bit like the subtle philosophical differences between two dialects of the same language, say Received English and an inner-city slang.
> There should be one-- and preferably only one --obvious way to do it.
The follow-up I think hammers home the subjectiveness of ‘obvious’:
> Although that way may not be obvious at first unless you're Dutch.
Perl lets you get under the hood in a way that either is frowned upon, impractical, or prohibited in other languages. So there's a language for every temperament now.
For example, in Perl, [if you wanted to], you can roll your own object system. That makes some people happy, and other people uncomfortable. But much of Perl has moved on to one very cool object system, Moose.
The Tim Bray article reads as if he's unaware of Modern Perl and all the Perl 6 stuff which has been back-ported to Perl 5. In all honesty, I had to check the date because the article had a 2002 feel to it.
[ This doesn't really matter much for long-running scripts or controllers in a webapp, but it does for a lot of other applications ]
use strict; use warnings; is not required. Moose is not the default object system.
You can't say, "Oh, this library has that feature!" Thats not good enough. It has to be built-in, not optional, core to the language. If you're working by yourself - you can write code in any language well. In groups, that is NOT the case. Writing Perl in groups requires rigorous code reviews and cooperation, and even then nightmares are hard to avoid. Expressiveness has its downsides. You cannot simply bring a Perl noob onto a project and not have him ruin it. You CAN bring a new Rubyist onto a project and they can be productive.
These assertions beg proofs.
CPAN is core to the Perl language and deliberately so. If you don't like this ethos then Perl isn't a "language" you should consider.
This begs the question, what's core? Python's regex could go either way, for example.
In short, I think some people feel that there are too many ways to do it.
Anyhow, that said, I think that people are too quick to write Perl off. Some of us are still writing Perl. Maybe I'm not doing anything big or fancy, but it's all documented, readable, and every single script on my computer uses warnings and strict. If you compare Perl to duck tape, I'd be like McGuyver: always keeping a roll of it in my pocket.
I've looked back at some of those one-offs, and for the life of me I can't tell what they are supposed to do.
On the other hand, I have written some largish projects in Perl, and when I constrained myself to a very explicit dialect of the language (almost Javaish in verbosenss), I found it to run fast, and be highly maintainable. I cracked the code open to a 20k line project I wrote 4 years ago and was able to jump right in.
In that respect it's a bit like C++ in that you can write code to be unreadable or you can write it to be readable if you constrain yourself to a non-idiomatic subset of the language. But unfortunately, the Perl community tried to embrace and open attitude towards this (there's more than one way to do things) that ultimately ended up embracing the "get it done now and in as few lines as possible" idiomatic unreadable code style.
I think other than that, OO is an important factor, Perl's OO system was so hard to do right, and other languages OO just seemed to embedded and clean to work with, but also Perl has not really found itself (for some reason) in many embedded systems, in GUI programming, on client-side systems (e.g. Javascript), etc. all places where it could have done well, but for whatever reason just never found a good comfort zone the way it does for sysadmin type tasks (and a few very small domains like computational linguistics). The Perl community seems to have spent a decade endlessly spinning around the drain of supporting backend work, and never approached the more sexy applications of the language.
Also, Perl 5 tends to be used for a lot of unglamorous admin work. So, although almost everyone's got a few utilities or cron tasks on their system written in Perl, they're not shouting about it from the rooftops.
Also, Python is an easy language to learn, and so people like to learn it and blog about how easy/nice/shiny it is: http://xkcd.com/353/ .