> I've developed an aversion to anything that doesn't 
  > follow the Zen of Python: "There should be one-- and 
  > preferably only one --obvious way to do it."

I completely agree, and sometimes productivity absolutely demands that developers become more expressive. I've found Java overly restrictive in the past, and have spent time learning Python, Haskell and other languages (and seen decent increases in productivity when I feel less fettered by the language I'm programming in). That said, I've also come to appreciate the effect of more restrictive languages: readability and long-term maintainability. Coming back to old code can always be jarring; having to maintain decade-old Perl written in a variety of different styles was maddening.

While you can screw up in anything, it's worth appreciating that more expressive languages effectively hand you more "rope" :).

Interesting... I wonder how many languages can still run a decade old program?

This shows both the strength and weakness of Perl in that...

i) It has excellent backward compatibility

ii) So no one is forced to improve or update the program (over time) :(

Do you have any source to back that (honest question)?

http://www.galois.com/~leepike/fm-galois.pdf

The features are very orthogonal and thought-out and much of the old legacy cruft is removed.

I've never coded in Python, but spent a little time in Ruby and liked how they knew you could do things many different ways, so the community and leadership focused on identifying and promoting idioms. I think that's a key factor in adoption. Perl had some of that (and the excellent "Effective Perl" had a chapter on it), but you need to make it part of your culture.

Yes it does need to be part of your culture. And there is no reason for a Perl team/shop not to because best practise idioms are heavily preached [1] and baked into [2] Perl and its community.

[1] Modern Perl movement & Perl Best Practises (http://en.wikipedia.org/wiki/Perl_Best_Practices)

[2] Perl::Critic (https://metacpan.org/module/Perl::Critic), Moose (http://moose.perl.org), EPO extended core (http://www.enlightenedperl.org/extendedcore.html), etc

> There should be one-- and preferably only one --obvious way to do it.

http://fold.sigusr2.net/2010/03/guido-on-functional.html

http://python-history.blogspot.com/2009/04/origins-of-python...

has some notes on the history of functional tools in Python, though not much reasoning.

> Curiously, the map, filter, and reduce functions that originally motivated the introduction of lambda and other functional features have to a large extent been superseded by list comprehensions and generator expressions.

What happened when you tried?

Just curious, though -- was that Perl codebase written and factored correctly, or was it already a big mess when you got it?

Ok, so which language(s) are you using then?