It's interesting how familiar this sounds looking at it from the other end. I've been programming in Perl for 15 years, but only once have I been hired as a "Perl programmer." Normally I get hired to sysadmin a server, or put a company's database online, or alter some chunks of text on a thousand web pages. Perl is the language I pull out of my toolbox for most things, but the client doesn't care (or know, usually) what tools I use, as long as the job gets done.

I'd be glad to get paid specifically for writing Perl, but when I go looking for such jobs, a lot of them have those "ideal candidate" lists you mentioned, which seem designed to eliminate most applicants. I've used loads of Perl modules, and I know where to find more and how to learn how to use them. But am I an expert in any particular laundry list of modules? Probably not.

For instance, I've dabbled with Moose, and if I need to know that for a project -- perhaps I'm taking over a half-finished project that depends on it -- I'll study and get up to speed on it. But if you say you're looking for Moose programmers, I won't apply for your job, because I'll assume you're looking for people who don't have to keep using perldoc to fill gaps in their knowledge of one of your basic requirements. I don't want to go to an interview and be unable to answer a question that's right from the first page of the perldoc, no matter how quickly I could find and use the answer during the job.

So I agree: unless it's a work in progress with a group of programmers, so the candidate needs very specific knowledge to contribute, it'd be better to explain the problem you need solved, and not get caught up in the tools. If you want to scrape web sites, just say that. Don't say you need someone who's an expert in WWW::Mechanize, because then you'll miss the guy who prefers a different tool -- or has even written his own.