Perl
Martin blogs about how the Camel book mentions the fact that scalars, arrays, and hashes have completely separate namespaces, as if this is a problem. Well, I disagree.
As with anything in Perl: yes, obviously it's possible to confuse yourself with this feature, and yes, obviously it's true that if you do this, you will get to keep both pieces of your program. So don't do that then.
However, when used properly, I find that it actually helps me improve readability of my programs.
Let's say we have a subroutine which returns a reference to a filehandle to a bunch of data in a format that we know how to parse. We don't know what the filehandle points to (and we don't care, either), but we do know what the data is. So we store the filehandle in some scalar, and then proceed to parse the data into a hash.
Now we could use variable names such as $fh and %hash, but I'll hope that everyone agrees with me that this is very bad practice. So, instead, we should name the variables after what they contain. Say our data file contains books:
$books = get_books_fh(); while(<$books>) { (... parse $author out of $_ ...) push @{$books{$author}}, $_; }
The filehandle to which $books is a reference, points to some useful data; and the %books hash table contains the exact same data, only structured in a different, more useful way. So why give them a different name? They're the same thing, call them the same way. Personally, I find this makes a whole lot of sense. And you can do the same thing with arrays vs hashes, or scalars vs arrays.
Of course you can also write code that uses $somevar and @somevar, with no semantic connection between the two. That is stupid, so don't do it. The fact that you can do stupid things with Perl, however, should not mean the language sucks.
You see, other than some other programming language I could think about, Perl does not assume its users are stupid, or inexperienced, or dummies, or whatever. Yes, that does mean that new users will get confused; but it also allows experienced users to Get Stuff Done in a proper way. And, well, I'm sure you can do stupid things with python, too.
@books and %books are only the same right after the loop, they are not tied to each other. Anyway, you misunderstood my point. I can well see how you make use of the funny characters properly, I just find it ridiculous that the book points out that this is a feature, that the compiler is smart enough not to get confused. pshaw!
Also, please don't spread the fud that Python people assume their users to be "stupid, or inexperienced, or dummies, or whatever". Of course, you can do stupid things with Python, but the important thing for me is: I can read anyone else's Python programme and understand what it's doing in a few minutes; I know that even Perl seniors have problems with that. And I never had to read documentation, I learnt Python just by using it. Those two are the best arguments for Python I know. Those two are why I prefer Python to anything these days.
Well, don't get me wrong, I like perl and used it for years (and still do so), but I don't think that $books{$author} being part of a hash you are filling, while $books is a (reference to a) filehandle is something that is easy to understand. This alone makes it hard for me to read certain bits of (someone else's) perl code. And to be honest, I still have my problems understanding when dereferencing is needed, when it is optional and when you should pass on without dereferencing. Just to note another difficulty with perl. I don't think that you should use the same variable name for different things unless the differencing part (a type classifier/sigil) is invariant while referencing the same variable. I.e. with Perl 6, the above situation will be a lot less confusing, with %books{$author} and $books.
Unless it's a trivial program solving a problem you've already solved in exactly the same way you've solved the problem before (or you happen to be the Buddha), I call shenanigans.
Domain knowledge tends to be at least somewhat important in understanding code, and Python has no features which magically encode domain knowledge in the most obvious and transparent way in code.