My thoughts on this can be summed up in a phrase: "Right tool for the job."

How do you go about figuring out the right tool for the job? Glad you asked!

Some (but not all) of the criteria I used for picking a language for a task is as follows:

• Am I going to have to redistribute the code or
• does my code have to run on random clients?
• How much work am I going to have to do to get the language to do what I need it to do?
• Do I have to spend time learning this language before I can write my code and do I have the time to do that?
• Is the lifespan of the end product short or long? And with that thought:
• Is someone going to have to maintain this code after I'm done with it and what are the skill sets that are available or expected in future maintainers.
• and kind of summarizing some of those thoughts: portability...portability...portability...

I have to confess that I have yet to write something that has gone production in Java. Not that I haven't started to, but somewhere along the line I run into something that I intended for Java to do that I couldn't make it do and I threw my hands up in the air and found another way to do it. So some of my opinions about Java are colored by my perceptions of the language.

On the other hand for heavily UI/Web based applications I might consider writing a Java UI to run on a user's local browser and use Perl as my backend to collect and ship data.

Another consideration that I did not list above that is an important one to you professionally is if the technical direction of your company expects you to code in Java (or some other language) and you refuse then this could be reflected negatively in your next performance appraisal. The exception (possibly) to this is if you are considered a big fish in your local pond and you can convince whoever is setting the techinical direction that there is merit to doing something other than the set technical direction.

Just my US$0.02 worth...