Q:

Balance between "right tool for the job" and familiarity

So when choosing what language to use for a project, in an ideal world the language is chosen because it's the right tool for the job.  However, I often prefer to use a language that I am fluent in rather than one I would have to learn or that I am only conversational in.  Of course language fluency also entails knowledge of the applicable libraries in the language.  Just because I really like a fairly general-purpose language like Java doesn't mean I should always use it, but at the same time it doesn't mean I should break out something like Perl every time there's some text processing to be done.  How does one find the balance here?

A:

Wow that is a VERY hard question when taken out of the world of theory and into the world of production.
In Theory
Simple. Always use the best tool for the job, and just learn what you need to.
In Practice 
Not only is there the question of your fluency there are a host of other business questions that need to be asked before you can answer this :

Cost of purchasing the "correct tooling"
Cost of supporting this  - people need to be trained
Cost of learning curve
Integration cost with other products ( now and into the future )
... etc

Outside of the theory there are serious ramifications for your technology choice.
Now I am not saying don't pick the correct tool - just make sure the correct tool will be able to break even on its cost implication.
If this is a personal project - always use the "correct" tool - so when you are faced with this decision in the business context you can make a better informed call.

A:

I think familiarity is not given enough credit. Your familiarity very well influences what the right tool is. You have to use the tool to complete your project. Furthermore, using something you enjoy can without a doubt exceed any shortcomings in it's fitness because you'll be more excited to get work done and you'll have better results.
http://headrush.typepad.com/creating_passionate_users/2006/08/when_the_best_t.html

A:

This isn't really resolvable except as a business question. However, a lot of business questions are made only looking at short-term numbers, which is a mistake with things like this.
My general approach:

If it's a small or short-term thing, always write it in the familiar tools.
If it's a big, long-term thing, look at the cost-benefit tradeoff of learning a new tool.
If you aren't sure, treat it as a short term thing until you have evidence that it's a long-term thing. Then go and look at the decision again.

Three things to keep in mind as you think about cost and benefit: One, people in a hurry tend to short-change the future. Two, maintenance costs are the lion's share of the costs for any successful system. Three, good developers like learning things, and keeping your developers happy is a good long-term investment.

