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?
Wow that is a VERY hard question when taken out of the world of theory and into the world of production.
Simple. Always use the best tool for the job, and just learn what you need to.
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.
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.
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.
Great question! As whatsisname said in his answer, "familiarity is not given enough credit." A different tool, different framework, different language could be a lot better than what you're accustomed to using, and you'd still be a lot less productive with it first time around as you learned the ropes.
I've been working for some years as an ASP.NET developer in digital agencies where we have a mix of big projects, small projects, tight projects, well-padded projects, etc. What we try to do, to expand our skills, is look for "soft targets", smaller projects which don't have painfully tight and hard deadlines, and use them as an opportunity to use new tech which might be superior. .NET 2.0, 3.5, 4.0, ASP.NET MVC, Linq to SQL, Entity Framework - all of them, I've used for the first time in such a project.
If you can take your opportunities like that, then hopefully, you'll be ready with a bigger suite of options to choose the right tool without suffering a lack of familiarity. Just like in Julio's example: they found a target where they could add Ruby to their repertoire, and now going forwards they can choose between Java and Ruby.
But if the deadline is short and solid and the project is important, I'd recommend you stick with the familiar tools. Something different might be better suited, but in projects like that, it's all about risk.
This depends on a few things:
1. How good you are at learning new languages or tools.
If you are a quick study, the barrier to learning new languages or tools is lower. This gives you the opportunity to add another tool to the toolbox.
2. How language/tool independent you make your work environment.
If your workflow is highly tool dependent, then the barriers to learning different languages are higher. If you are wedded to a particular IDE, then switching languages involves significantly more than just learning a language, since editing text will surely frustrate you.
Someone using vim or emacs does not have this problem. All they have to do is learn the new language.
3. Business reality
Learning new tools/languages takes time. That time has a cost. But that cost has the potential to be an investment that pays back more than the initial expense. Also, an ungainly solution will usually take longer to implement and be harder to maintain. If it's anything larger than a small project, and the tools in my existing toolbox don't seem to suit the problem, I will research which tools DO suit the problem. I've also invested in an environment to suit a generalist approach, learning to use vim as my chosen editor.
Another thing - what is the shortest distance between two points? If someone else has written something that nearly does what I want to do, it is usually quickest to just modify that to suit my needs.
If there's a new language you are curious about, and you (and the business) can afford it, why not give yourself a couple of weeks to a month to explore it?
This is how I learned ruby. My coder partner had 7 years experience with Java. I had 11 years of Java experience. Neither one of us knew anything about ruby, only that we wanted to try it.
I convinced him and the rest of the company to try ruby for a month (this was going to be a 6-8 month project). Worst case, we would start over this time using Java.
Luckily after a week we were hooked, so it turned out okay. Perhaps you can try something similar? See if you can build something from scratch in some other language, but making it clear to the business why you're doing it, and at least as importantly, what plan B is in case the experiment fails.
There is obviously no single answer to this question that will apply to all situations. But here is an aspect that I don't think has been mentioned yet. If you are a developer you should also take your own marketability into account. If language X is chosen for your project, how will that look on your resume? It may be a good idea to choose a language that you are not familiar with so that you have a reason to learn it, expand your intellectual horizons, and make your skill set more attractive for future employers.
My own version is to "use the right tool available to me" for the job. Being "available" means that I am able to use it, not just that I can buy/get the compiler and//or runtime.
In almost any real life scenario, given a problem you have very limited time to solve it. I don't believe you can truly learn a new language in a very short time. Learning a language means actually reading books, going through other people's code, understanding how it works and the philosophy behind by it. One could just read a tutorial off the web (which is perfectly good as a starting point), and get hacking. But that would lead to terrible code and you would probably be better off writing better code in a language you know in possibly much shorter time.
Despite the merits of the "right tool for the job" proverb, most popular languages are actually general purpose. They may have strengths in certain areas, and not be as good as others in other areas, but they can get most jobs done. Not knowing a language practically means that tool isn't available to you.
I am not saying just learn one (or even two or three) languages and use them for all projects and don't learn anything else. It is important to learn other languages, to acquire more tools to add into your toolbox. But faced with a problem, it is better to stick with the tools you know rather than add to your worries by using unfamiliar technologies. But keep learning other languages so that the next time the choice is easier.