One of the Bugzilla maintainers posted a blog entry on "The Problems of Perl" (on LiveJournal, love the irony
It's spawned a lot of discussion and some advocacy (ugh, advocacy). One of the points I've seen come up several times is that the author complains about something in Perl, and someone suggests a module that might help, to which the author replies "I'll check that out."
In a few other threads the author has claimed to know Perl pretty well.
In reponse to that a few folks have said "well, if you don't know about Module X you don't know Perl."
This brings up the question of what it means to "know" Perl. Personally, I tend to agree, this blog author really does not know Perl. He may be able to read Perl well, and he may be able to write clean Perl, but that's different from really "knowing" the language.
A programming language is more than the sum of its syntax. In that sense, I know C. But in the sense of actually understanding the lore and spirit of the language, I don't know C at all. But the word "know" is pretty loaded here, and it's easy to interpret in many different ways. Let's try to come up with two different terms.
For someone like this blog author, I'd say that they are "competent" with Perl. They won't be flummoxed trying to read Perl, if you give them a task to code in Perl they can do it without writing something horrible, but they won't do the best possible job either, because they don't know enough to do so.
For the other version of "know", let's say "expert". An expert knows more than the syntax, they know the lore. They're aware of the ongoing community and discussion behind the language. For Perl, a large part of this means being aware of what's on CPAN, and knowing how to use it to solve problems. It probably also means going to mongers meetings, conferences, reading mailing lists, hanging out on Perlmonks or IRC, etc. You don't have to do all of those, and you don't really have to be an active writer/speaker, but you have to have some level of involvement.
Achieving competency should be a pretty quick process for anyone who's competent in another language. Once you've learned the syntax and some core libraries, you can apply your existing design skills to write not-too-horrible code.
But achieving expertise is much harder, and it's an ongoing effort. Right now I'm definitely a Perl expert. If I went away for two years and came back, I'd probably just be competent, and it'd take catching up to become an expert again.
In practical terms, I'd prefer to work with experts than competents, but I'd hire a competent if I had enough experts on the team already to make sure the competents do expert-level work. A team of competents will produce an okay code base, but one that reinvents many wheels, and has a lot of niggling problems.
Unfortunately, it seems like employers can't even distinguish between competent and incompetent, much less between competent and expert. But that's a whole 'nother journal entry.