Picking up, while easy, isn't terribly useful. You have to know the non-obvious pitfalls and the 'right' way of doing things.
You also need to develop a full understanding of the package/library/framework ecosystem, which can take years. This isn't transferable knowledge, either, but it's absolutely vital to understanding a language.
Knowing that requests is a great python library, for instance, and knowing when (and when not) to use it isn't going to help much when picking up Ruby, let alone something like Go or C.
I've seen good, experienced programmers pick up new languages and consistently step in the many of same traps that beginners do, simply because those traps aren't very obvious.
I think what you're describing is "being an expert" rather than "being proficient."
If a project requires expertise in a specific language then sure, shoot for "an X programmer" (there are very, very few of these in reality). Otherwise "a programmer" (who is good) will almost certainly be able to perform the job, and do it well, all other things (e.g. motivation, interest in actually using the technology in the project, etc.) being equal.
Comments
Picking up, while easy, isn't terribly useful. You have to know the non-obvious pitfalls and the 'right' way of doing things.
You also need to develop a full understanding of the package/library/framework ecosystem, which can take years. This isn't transferable knowledge, either, but it's absolutely vital to understanding a language.
Knowing that requests is a great python library, for instance, and knowing when (and when not) to use it isn't going to help much when picking up Ruby, let alone something like Go or C.
I've seen good, experienced programmers pick up new languages and consistently step in the many of same traps that beginners do, simply because those traps aren't very obvious.
I think what you're describing is "being an expert" rather than "being proficient."
If a project requires expertise in a specific language then sure, shoot for "an X programmer" (there are very, very few of these in reality). Otherwise "a programmer" (who is good) will almost certainly be able to perform the job, and do it well, all other things (e.g. motivation, interest in actually using the technology in the project, etc.) being equal.
It seems that the 'Effective Go' article was written to avoid the pitfalls. I agree with your point, but I don't think it's a very strong one.
http://golang.org/doc/effective_go.html