What exactly does that mean? It's a vague response that people have used for years when they don't want to explain why they chose a particular tool. In my experience, many developers take the path of least resistance and use what they are comfortable with and that's why "it's the right tool for the job".
The problem is more that writing a post that is a list of if you have problem X use solution Y is a nonstarter. People like different things, have different skill sets, and are dealing with a different set of requirements. Finally, it is the sort of thing you would have to keep up to date with the latest version of every framework, language, and OS.
To discuss by means of example, lets talk about floors.
You decide to redo the floor in your place of residence. Do you:
0. Hire it out, using a cheap contractor
1. Hire it out, use a vendor in the middle of the quality/cost curve
2. Hire it out, using the classiest floor shop in town
3. Do it yourself, using a rental sander and a youtube video for training, sand your floors down and refinish using stain the guy at Home Depot recommended
4. Do it yourself, tear the floors out and replace them from the beams up using reclaimed lumber from the local artists collective.
5. Do it yourself, linoleum is fast to install, looks okay, and its super cheap.
6. Do it yourself, spend 6 years learning carpentry from a master artisan in the wilds of Scandinavia, fell your own timber using an axe you made yourself, assemble the timber into the master work of flooring using expensive danish hand.
Personally I try to do #1 for floors and #4 for software but that doesn't meant that works for you. If you have already done the first half of #6 I would be temped to just go all the way.
That said if someone gets bored we could do a sort of survey on a timed basis and rate different tools for different strengths ans weaknesses. Something where you could be like "optimize speed of development versus XML Parsing Quality" and it would give you a nice chart as long as you provide a few quick survey answers.
Might Give writing it a try later on. would be interesting to see what metrics people cared about.
Sometimes that's exactly what it means. The reason you see frameworks like Rails catching on, slow and bloated as it can be (and I say this as someone that loves the RoR ecosystem), is that developer time is generally more expensive than CPU time.
Couldn't agree more.
Business (the people who pay us to code) generally doesn't care about performance if it's "good enough to ship". Time to market, on the other hand, is a matter of life and death.
Life and death also hang on other factors that swing the argument in the other direction, like can you scale quickly if you are the next big thing, are you stable, is your uptime acceptable, are there huge security holes that can tear your company to the ground over night...
Speaking in generalities isn't very useful.
Each project has to weigh the pros and cons of each decision. It's basic engineering.
Well, why not? "My team and I are familiar with these tools and confident that we can use them to deliver the desired result" seems like a fine reason to call something the right tool for the job.
They aren't the same thing but there's basically no room between "these are the tools I know"-thinking and "if all you have is a hammer"-thinking.
Freely admit this is somewhat irrelevant though as most languages are the difference between a felling-ax and a splitting-ax or two sizes of screwdriver, as opposed to hammer vs drill.
Well, I assume most people have a handful of tools they are familiar with and choose from among them (although the proliferation JavaScript-based stuff absolutely everywhere might call that assumption into question).
What exactly does that mean? It's a vague response that people have used for years when they don't want to explain why they chose a particular tool. In my experience, many developers take the path of least resistance and use what they are comfortable with and that's why "it's the right tool for the job".