So perl is not hard to read because there's a book about best practices, and optional libraries that enforce coding styles?<p>I respectfully disagree. Reading perl requires understanding a significant amount of perl-specific trivia for any given block of code, that's why it is hard to read.<p><a href="http://shootout.alioth.debian.org/" rel="nofollow">http://shootout.alioth.debian.org/</a> Binary trees problem.<p>Perl:<p><pre><code> sub item_check {
my ($tree) = @_;
return $tree->[2] unless (defined $tree->[0]);
return $tree->[2] + item_check($tree->[0]) - item_check($tree->[1]);
}
</code></pre>
Lua:<p><pre><code> local function ItemCheck(tree)
if tree == 3 then
return tree[1] + ItemCheck(tree[2]) - ItemCheck(tree[3])
else
return tree[1]
end
end
</code></pre>
These demonstrate the REALITY of what it's like reading perl code vs. other languages. Count the number of different symbols you must know in order to understand the perl code, versus the number of symbols you must know to understand the lua code. Anyone familiar with functions, variables, and standard control flow will be able to read the lua with no problem. If you look at other code snippets, like Javascript and C#, you'd amend the comment to say that anyone familiar with methods and object-oriented programming will be able to read the code with no problem.<p>With perl, you have to know perl. You have to know perl's control flow ("unless"), you have to know perl references(->), you have to know perl's parameter passing semantics and the meaning of @_, and you have to know perl's variable prefixes.<p>That's why perl is hard to read. That's why people who use perl all the time don't understand why it drives everyone else crazy. They have all that crap in their heads already. You never smell your own bad breath. Style guides don't fix this problem.