It turns out that native speakers use a far broader footprint of the language, and reference all sorts of cultural idioms when they speak. And so the non-native speaker has no idea what they're talking about. But two non-native speakers are both using a smaller, common, conservative subset, so there are fewer misunderstandings.
* * *
Everything at topix is written in perl. That sometimes elicits the "What's up with that?" from techies. "Perl looks like line noise. Isn't your code hard to maintain?"
Well, as hard as anyone's I guess, but not because of the language.
We do crazy fun stuff in our system, like mmap'ing giant files with key-offset indices at the front, pulling out chunks of data, decompressing them, and thawing them into perl objects. We can do something like 6,000 of those a second on a regular box. We now have a scalable get/put service based on that running on a 500 node cluster. We do named entity disambiguation and all sorts of text analytics in perl. Performance isn't an issue, not from the language anyway. We worry about disk seeks and network latency and stuff like that. But not statement execution. There are a handful of functions that got written in C but it's pretty tiny.
"What about python and ruby?"
I think that anyone using perl, python or ruby is about 100X more productive than someone working in Java or C++. Within the three I don't really have strong opinions though.
If you choose to deliberately limit yourself to a subset of whatever language you're working in, code can pretty much come out looking the same in all three.
Trouble starts when you try to get fancy.
I see gee-whiz programmers often gleefully code wonderful stuff that no-one else can make heads or tails of. Certainly not the new junior engineer we just hired who was a sharp coder in two other languages, but just started learning perl a few weeks ago.
And the gee-whiz stuff doesn't buy much. You can trim out a few lines here or there, but often the complexity is more at the greater system level, and the performance has to do with the systems and algorithmic stuff. Obfuscating a few lines to leverage a language trick doesn't actually benefit the system, and it certainly doesn't benefit the other members of the team who might have to pick up that code later. Coding is social, it's not just a private dialogue between you and the machine.
I've known a lot of languages in my career. I've studied language design and written compilers. I see big productivity differences between classes of languages, but within the classes, not so many. But folks always seem to get religious about one vs. the other. Frankly, it's a red-flag. It signals idealism over pragmatism, a love of a particular toolset over a focus on the goals of the project.
Ulysseys is great if you want phd english majors to study your work for years to figure out what it means. But put the five dollar words away when you're writing the install guide for your new blogging package. Coding is the same way. Put the fancy stuff away and code for the rest of us mortals.