From: PickTheRightToolForTheJob

I'm sure this is better than picking the wrong tool for the job, but it isn't
easy to know what the right thing is.  It isn't easy to know all the requirements, and it isn't easy to know what tool set those requirements
imply, especially as both tool sets and requirements are apt to change.

I'm not suggesting it isn't worth some effort, but I suspect a more plausible
goal is PickAnOkToolForTheJob.

----

'''Forces:'''

	* If information was costless and guaranteed correct, you would like to PickTheRightToolForTheJob
	* However, it takes time to evaluate every tool under the sun. Do you know how many programming languages exist? Thousands!
	* Moreover, you don't know what the job will require until you have actually completed it.

'''Therefore:'''

Pick an OK tool for the job. Don't try to pick the ''best'' one, but try to pick one which you are pretty sure is at least not so bad that it will seriously hamper your work. After all, in the end ''you'', not the tool, will have to do the real work.

'''But also:'''

The bigger your toolbox, the better the chances are that the best tool you can muster will be good enough (or even better than just "good enough"). Therefore, work actively to increase the range of tools you are comfortable using so that you don't end up having to do text-munging in C or heavy-duty numerical optimization with Excel. -- The fact that an OK tool, rather than the best possible tool, is what you need, shouldn't be made an excuse for not knowing enough tools to be able to choose an OK one.

-----

There's a lot to be said for having a good tool box:
In general, the more powerful the tool, the more narrow its scope.
Tools that enable great leverage on some narrow range of problems often perform poorly outside that range.

For example, a good reporting tool may not be well suited to complex batch server background processing (with no printing).

So, use good tools, where available, for the parts of your application where the domain is well understood and supported by 3rd party tools:
	* Database
	* Reporting
	* GUI
	* ''(and others...)''

----

''On the other hand, it's often more productive to use a less appropriate tool that you've mastered instead of an unfamiliar tool that's more appropriate to the problem. For example, I often use Java for tasks that would be better suited to perl. Sticking to a single language lets me concentrate on higher level concepts and accomplish a great deal.''

It is also sometimes appropriate to use a single tool to develop a set of related components, even if it is not the best tool for any of those components.  For example, a VB GUI that uses a C++ COM component to make calls to web services implemented in Perl and Java may be more difficult to build, debug, and test than a solution that uses C++ throughout.

On the other hand, if part of your system has low-level device driver stuff that absolutely requires assembler code, it's usually more difficult to build, debug, and test an all-assembler solution than one that uses mixed assembly and C++. Use each tool where it works best (or at least, where there's not some other tool available that's clearly superior).

Given a large job, sometimes the best thing to do is not to pick a single OK tool for the entire job, but to split the job into smaller jobs, then PickAnOkToolForTheJob for each one -- or pick one or two or possibly 3 tools, and figure out which tool is best for each little job. Often some little job is stuck over in the "assembler" part. Then when users ask for additional functionality ... it's better to refactor and move that no-longer-little job over to the "C++" part.

LotsOfLittleTools LittleLanguage