Pick The Right Tool For The Job

Don't try to hammer a nail with a monkey wrench.

Don't use a screwdriver to pound nails. It takes forever and wrecks the screwdriver.

Based on requirements, always pick the right tool for the job. -- DrewMarsh

Yes, always. Identifying your ProblemFrame can help with this. -- KeithBraithwaite

In practice, few people seem to be able to pick the right tool, because they don't know enough different tools. Also, the right tool for a job happens to be highly dependent on who is going to use it. Maybe this leads to PickTheRightProgrammerForTheJob?? (or SpecializationIsForInsects)

The LukeGorrie story on LanguageAgnostic drives this point home. I'd seek to employ someone like Luke every time, vs someone who can recite the latest Java API verbatim (or, in past days, the ARM). But I'd also take a chance on someone who showed the ability to be trained into a Luke. -- KeithBraithwaite

I feel compelled to admit that, because I'm a beginner Scheme programmer, doing things the way I did took longer than it would have taken me to do everything by hand. :-) I rationalize this by saying that it gave me experience with this KawaScheme -> JavaLanguage compiler that I hope to use heavily in the future. -- LukeGorrie

Don't underrate yourself Luke, there are few developers around who would even think of proceeding the way you have, let alone do it. -- KB

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.

IrreverentDyslexia? alert. When scoping out jobs and considering tools, don't forget to also PickTheRightFoolForTheJob?, especially if you want it done right.

An alternative could be PickTheRightJobForTheTool.

Managers' alternative: PickTheRightFoolForTheJob?.

OK, let's face it. The language list (http://cui.unige.ch/OSG/info/Langlist/intro.html) contains 2350 programming languages. I bet you didn't evaluate them all before embarking on your current project. This is a typical example of where it is irrational to be fully rational. Everybody uses a shortlist, and this leads automatically to PickAnOkToolForTheJob. But why wasn't the HaskellLanguage on your shortlist?

[This sort of decision-making is known as in economics theory as 'satisficing' (http://en.wikipedia.org/wiki/Satisficing), and is unavoidable in any situation where there is insufficient information to determine absolute optimality (i.e., any non-trivial real world situation). While it means that it is usually impossible to find an optimal solution, it does not serve as an argument against attempting to find a better solution. - JayOsako]

Ok, you have 2350 languages, but how are they related? I have heard someone claim that they had a "broad" programming background because they knew c,c++,java and a bit of perl (this was a while ago, I am sure that today they would add c# and python, etc.). While laughable, these sorts of claims are not as rare as one might hope. Compare to someone who knew, say, smalltalk, lisp, fortran, and a bit of java....or some permutation

This sort of decision-making is known as in economics theory as 'satisficing' (http://en.wikipedia.org/wiki/Satisficing), and is unavoidable in any situation where there is insufficient information to determine absolute optimality (i.e., any non-trivial real world situation). - JayOsako

I am not sure how to pick the right (i.e. absolute best) tool for the job. I can pick an adequate tool for the job. Isn't that sufficient?

If "adequate" means "right," then yes.

RE: [...] languages are simply tools at our disposal, a skilled carpenter could attempt to use his saw to lever out a bent nail but it would take alot more time and lateral thinking, but the claw hammer is just laying there doing nothing. Every language has its time and place. [...] I dont think it is possible to create a magic-bullet language, and no one should try. [emphasis added, originally from CeePlusPlus]

It is true that languages are tools and that there is merit in choosing TheRightToolForTheJob. But it isn't often that just one 'tool' is right for every part of a job. Running with your analogy, a typical project may call for both the saw and the claw hammer. Unfortunately, putting too many tools in your toolbox starts making that toolbox very bulky and heavy - difficult to manage, difficult to learn, and difficult to afford. The same is true of software tools... well, they don't have any physical weight, but they do impose a large learning burden, configuration management costs, and so on (different editors/compilers/interpreters; different forms of managed memory; unwieldy, unsafe, and inefficient ForeignFunctionInterfaces; challenges supporting optimizatons/safety/security/reliability/debugging/error handling/logging/transactions/MT-safety/and various other CrossCuttingConcerns between multilingual components; etc.).

Because there is a hefty price-tag associated with keeping extra languages in your language-toolbox, PickTheRightToolForTheJob, no matter how practical it sounds, is not, in practice, always practical. As a result, there is also considerable merit in the idea of a GeneralPurposeProgrammingLanguage that aims to be all things for all projects. Even when such a language does not provide TheRightTool, it will often be GoodEnough. But because it isn't possible for language designers to predict all uses of a language it is useful for a GeneralPurposeProgrammingLanguage to have the MetaProgramming facilities to extend it as required (much like the AllPurposeToolKit contains a $20 bill just in case). Similarly, because it isn't possible for project developers to anticipate or respond to all feature demands, it helps if the language makes easy and relatively efficient support for safe and efficient runtime extensions - AlternateHardAndSoftLayers and PluginArchitecture all within just one language.

Unfortunately, while CeePlusPlus does aim to be something of a GeneralPurposeProgrammingLanguage, it is far from ideal for such a purpose. The inability to modularize a new feature in a GeneralPurposeProgrammingLanguage without leaking implementation details or severely compromising NonFunctionalRequirements has been called the MissingFeatureSmell, and C++ positively reeks of it. It lacks, among other things, suitably powerful MetaProgramming facilities (TemplateMetaprogramming is not GoodEnough), and is awful at AlternateHardAndSoftLayers (bad enough that people have created dedicated general purpose languages that aren't CeePlusPlus to become the 'soft layer').

But, regardless of whether C++ is suitable to the goal, the benefits of having a single language that is GoodEnough for every task is very appealing, very practical, and well worth pursuing. The dream is enough to inspire such thoughts as the SingleLanguageOperatingSystem. The trick is to avoid the language itself becoming the massive and unwieldy toolbox aforementioned. We need a single, coherent tool - perhaps related to SymmetryOfLanguage. And even if it is 'impossible' to succeed 100% of the way, coming arbitrarily close is still likely to be a great deal better and more practical than is the situation today.

RE: [CeePlusPlus] is awful at AlternateHardAndSoftLayers (bad enough that people have created dedicated general purpose languages that aren't CeePlusPlus to become the 'soft layer').

Wait ... the whole purpose of AlternateHardAndSoftLayers is precisely to get away from lower-level, less-flexible langauges like C/C++ for expressing solutions to problems in their ideal notation. Your parenthetical qualification, therefore, serves no purpose as stated. Who ever would consider using C++ as a soft layer? However, many folks have invented new languages (the most famous of which is JavaLanguage) to avoid C++ like the plague that it is, for the purpose of serving as a hard layer. So, shouldn't you have written, ". . ., that aren't CeePlusPlus to be the 'hard layer'" instead?

A GeneralPurposeProgrammingLanguage should be able to AlternateHardAndSoftLayers without resorting to a different language. I do not believe that there should be a significant dichotomy between 'lower-level, less-flexible languages like C/C++' and 'languages for expressing solutions to problems in their ideal notation'; a GeneralPurposeProgrammingLanguage should be 'GoodEnough' at fulfilling both roles - fulfilling many such roles is what "general purpose" means. CeePlusPlus's failure to be good as a soft layer (no language-recognized modularity, safety/sandboxing, general lack of support for parsing or interpreting in its standard library, etc.) and its failure to provide expression of some problems in a GoodEnough (if not ideal) notation (due to weak MetaProgramming) are both failures of CeePlusPlus in its role as a GeneralPurposeProgrammingLanguage - which is significant because CeePlusPlus does not fill any roles as a DomainSpecificLanguage.

Other languages that purport to be GeneralPurposeProgrammingLanguages often have the same failing. For example, JavaLanguage should be the soft layer for JavaLanguage. It works for compiled Lisp and Forth. Why not Java and C++?

That people feel the need to "avoid C++ like the plague that it is" is because the lack of support for effective MetaProgramming and AlternateHardAndSoftLayers are just two among a myriad of failures for CeePlusPlus in its role as a GeneralPurposeProgrammingLanguage.