Not long ago I was mutually baited into an argument with one of our developers, in which he challenged me on why I had chosen Python for my most recent project. His claim that I didn't "know Python" he backed up with a few questions:

1. What is Python's method resolution order?
2. How does it bind variables on its stack?
3. Does Python implement closures, and if so, how?

Now, I'll be the first to admit that I don't "know Python". I can express my logic in the Pythonic vernacular, but there's much about it that I don't yet know about or understand. In much the same way as a person unfamiliar with English will use the imperative mood where the subjunctive is called for, it still works, but it's not done in the clearest and most accurate way.

I jokingly retorted that I didn't even know those things about Perl, not because it's true but to make a point. I know Perl (and I know the answers in Python, too). But I don't need to know its MRO, how it "binds variables on its stack", or how to write a closure in it, in order to write good Perl code.

"Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." -- Alan J. Perlis, "Epigrams in Programming", 1982.

Do you really have to know everything about X in order to "know X"? Do I need to know Python's opcodes and when they're invoked? Do I need to know Perl's SV, HV, and other such structs and the hints maintained therein? Really, half the point of using these interpretted languages is so that you don't need to know their guts.

So at what point do we say that someone "knows a language"? Is it when the person can write something in it that actually works?

print "I know Perl and Python and PHP.";

"Don't have good ideas if you aren't willing to be responsible for them." -- Alan J. Perlis, "Epigrams in Programming", 1982.

---

Add this page to your favorite Social Bookmarking websites