On a (possibly) somewhat more serious note, I do think there are legitimate reasons that I would never want to maintain large amounts of perl code, and they are rooted in the language itself.

It mostly stems from the fact that there are too many ways to do things (some of them supposedly added to make things more readable, but, in practice, having the opposite effect :-).

I would be willing to read and maintain my own perl code because I understand the subset of perl I use, and I don't need to know any other subset of perl because the other subsets don't actually add any new features, just different ways to say the same thing, but if I had to maintain perl code, I'd have to actually be able to read all the different idioms.

Just some examples: perl has about 1,247 levels of operator precedence, and some fools out there actually insist on minimizing the number of parens in any expression by picking || instead of OR, etc. No ordinary human being can actually parse crap like that - I'd much rather have the "ugly" parens cluttering things up just so I'd know, not only what the expression really means, but what the author really meant when he wrote it, in some ways APL is more readable :-).

Then there are I/O functions, vs object oriented I/O handle operations, then there are optional parens around arg lists except when they aren't optional, then there are $ref->{} vs $$ref{} then there are bare words vs single quotes then there are (at least) two different ways to call object methods then there are etc, etc...

You may get the idea: You can be a perfectly competent programmer, writing perfectly wonderful perl code and it can *still* be virtually impossible for someone else to maintain. You have to know a lot more perl to maintain it than you do to write it.

Yes, this is true for just about any language, but I often think it is far more true for perl than just about any other. (Mind you, I still love perl, but I can see the problems with maintaining it).