A lot of people say that "TIMTOWTDI is the main reason for Perl's write-only reputation", but I'm going to humbly disagree here. Instead, I argue that Perl's TIMTOWTDI- and 0222-ness instead both follow from something else: a huge language with lots of syntax that both mixes programming paradigms and manages to be unique at the same time. Here're a few examples of what I mean (please feel free to correct me or my examples if I'm or they're wrong!):

• A quick script I wrote shows that perlfunc contains 217 entries or so, with 331 usages or so. See also szabgab's Perl index. That's a lot of functions!
• Many people find the default/implicit variables $_ and @_ confusing. It seems to me that this idea is largely unique to Perl and leads to such problems as "why does ord() mean ord $_ but srand() does not mean srand $_?" or "why can't I omit @_ from map?" The lack of formal parameters (yes, I know they exist now, but most people don't use them) leads to things like sub mult{$_[0]*$_[1]}.
• Context! New programmers often have difficulty adjusting to the fact that functions return different values depending on how you call them. To some people, this seems like a violation of the "you can't know why I'm calling you, just do your job" abstraction for functions.
• Two words: regular expressions. Although they are perhaps one of the most useful things in Perl, period, they do have a lot of syntax associated with them. Consider the number of modifiers m//cgimosx; for readability, notice that spaces are interpreted literally unless the /x modifier is added. However, other languages are trying to import Perl's regexps (see Java) or their own variant (see C++ (Boost)). See also the line noise comment later.
• There are some logical things in Perl that are a little foreign to, say, C programmers. These include unless( FOO ){ BAR } or the BAR if/unless FOO variants of the same. But these too are sometimes unusual: in the script I mentioned above, I wrote print $1 if /^\s{7}(\S+)/'; what is the $1 here? You have to look ahead to find out. More reasonable things that take some time to get used to include allowing trailing commas in (1,2,3,) or allowing lacking ending semicolons in sub f{my $x = shift; $x**$x}, the <FH> operator, or an alternation operator || that actually returns the value that was true (so $var ||= $default or $var //= $default works as it should)
• Perl is nice enough to let you avoid parentheses wherever possible. This is great, but sometimes it's a little confusing, in particular when the "if it looks like a duck function, it's a function" rule gets in the way of an honest print (2+2), "\n".
• There are a lot of functional programming paradigms in Perl, an otherwise mostly procedural language, that are also foreign to C programmers. These include fun things like map, but also more complicated things like closures. Also, Perl manages to have both lexical and dynamic variables; compare Scheme, which has only lexical variables.
• Perl allows you to avoid a lot of spaces, allowing smushing of function and variables (func$var) and such.
• I think the most common Perl insult is that "it looks like noise". What contributes to this perception? I think it was the design philosophy of "Huffman coding" --- commonly occuring things are short. However, to make this practical, the "alphabet" was extended: the pattern m'[$@%#\\<>~]' fails on most lines of code in other languages. In addition, some things were overloaded (like {..} for hashes and functions). Regular expressions usually do not help, because they're pretty well Huffman-coded (although I think Perl 6's pattern matching is a step in the direction of both better coding and comprehension). Finally, things like $#$_ just baffle new programmers, I think (disclaimer: I think that Zaxo's response is good there and not confusing; I am just commenting abstractly). Note also the special variables, like $/ or $".
• I'm not even going into obfuscation. Notice that most obfuscated C code uses the preprocessor heavily.

This isn't a full analysis, but it's a start. What I'm saying is that TIMTOWTDI comes from some of the above (especially the function programming paradigms and regexes), but that the inherent nature of the above also causes write-only-ness. That is, they have a common cause, and not that TIMTOWTDI causes write-only-ness.

Disclaimer: By the way, don't get me wrong ... I love all of these things about Perl, particularly one liners and the interaction with the Unix pipe philosophy. I, however, have talked with many people who don't like Perl since I usually mention that it's my favorite language.

Update: Spelling, formatting, and such.

All those things are true.

$_ and @_ are confusing largely because there's no single piece of documentation which lists all the functions that assume $_, which functions will implictly set it, and so forth.

I'd add: perl is inconsistant. $_ acts like an alias inside a foreach, but doesn't have the same side effects outside the loop. @_ means @ARGV, or the parameter list, depending on whether you're in the main program body or not.

Perl lets you do things in inconsistant ways: this is part of the TIMTOWTDI design. Once you let there be multiple ways to do it (inconsistant design, that accomodates multiple ways to do the same thing), you don't worry about a few more inconsistancies thrown in here and there, even if they're confusing to a novice.

Try explaining the word, let alone the perl implementation of the term "autovivification", and watch the eyes glaze over really fast...

The lack of formal parameters (yes, I know they exist now, but most people don't use them) leads to things like sub mult{$_[0]*$_1}.

Huh?!? Do they exist now? Aren't you talking Perl6 by any chance? If so, then I wouldn't say "they exist now"...

Incidentally one of the things I like about Perl (but then I just love it to the bone in any case!) is how its simple parameter passing mechanism can be put to mimic so many different styles, e.g. by reference, by value, named.

Update: Incidentally I recommend that when you change the subject of a node within a thread you include the previous one. I've been bit in the neck by this myself. See my own post at Q re nodes' subjects.

Yup, sorry, I think you're absolutely right. I really don't know why I was absolutely blanking, but I thought I remembered seeing formal parameter lists somewhere, and I guess that was Perl 6. Indeed, perlsub mentions "Perl does not have named formal parameters."

I guess you could change my comment, if you want, to the fact that it's difficult to pass arrays and hashes into functions (with the canonical solution being references and the less typical one prototypes). Thanks for the heads-up.

Thanks for the title comment, too. Whenever I reply to an email and change the subject, I usually change the subject to "FOO (was Re: BAR)". I actually thought about doing it here, but I guess I misjudged when I thought that that would "clutter" the node. In the future, I'll do that; I think I'll let this stay for now.