By that, I mean that many times a particular tool my be a perfect fit for the exact job at hand -- but if after a dozen jobs, you find you've used a dozen different tools, then you have an extension and maintenance nightmare.
The problem is that the immediate job that you're thinking of is usually only a part of a larger job, which is usually something like "get all of these jobs done, and working, and maintainable, and done in such a way that we'll be able to do the next set of jobs well too." And that argues strongly for using a very minimal set of languages, so you can share code and have the various solutions interoperate well, and also so that you can draw upon the existing solutions in crafting new ones. This will necessarily mean that some jobs will be solved with suboptimal tools.
Extending the "job" further, you may also want to consider other people -- it's a lot easier to find people who know Perl and C than people who know Perl and C and Java and Python and Lisp and Intercal and....
All that is not to say that "the right tool for the job" isn't a useful metaphor. My manager recently asked why my engineering team had chosen use Perl rather than Java to write a set of command-line tools for managing our system. I looked at him with the same air of puzzlement that I would use if someone had asked me why I didn't use a dead fish to pound in a nail.
In reply to Re^2: Reverse Engeering of Learning
by sfink
in thread Reverse Engeering of Learning
by artist
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |