Chris Granger, the guy behind the Light Table idea talks a lot about domain specific tools and their importance. This put together with some thoughts I've had myself for a while now makes something very interesting. Have you ever heard the expression?

When all you have is a hammer, everything looks like nails -- the law of the instrument

I also remember some writing, although I can't remember exactly where, about how carpenters needs to learn what tool to use where, just as programmers.

Programmers face many different situations, in which you can apply many different solutions to your problems. There are many languages and infinitely many more techniques you can use in many of these situations. On of these techniques might be GPGPU-programming. Another might be C++11 constexpr metaprogramming. Others include, but are not limited to AST manipulating macros, design patterns (And OOP design patterns vs. FP design patterns are worthy of a blog post alone), assembly level debugging. But if all you know is say... Java, you can solve many problems, but in a suboptimal way. Don't get me wrong, some problems are very well suited for Java. It would be my first choice if I had to do some BigNum math. Better programmers might go for Haskell in that situation. My point is, the more you know, the better equipped and more able to provide a good solution you are. And every language has its perks and pitfalls, because essentially whenever you are doing anything practical, you are within one or more domains, and these domains have specific problems, specific solutions and hopefully specific tools. In order to perform good, you need to know about these specific stuff.

Whenever a programmer/software engineer is satisfied with what they know, it pisses me off. Because that means sometime they are gonna run into a problem and come with a terrible, if any, solution to it. Of course this can still happen even if you continually strive to learn more, but the odds are you will be way better suited to handle it. The same goes for people who are absolutely content with knowing (of) only one paradigm, which is usually OOP. When you decide to stay there you will lose all the insight there is to be found in functional programming.

Right now I'm doing a lot of C++, a language I'm quite terrible at, even though I have to point out it is horribly hard to master. I want to learn how to make better solutions to the problems I've got. I've already refactored the code base some into something better, but I know there are still things to be done better, so I bought a book in template metaprogramming. I hope it will help me write some awesome code. To tie this back to the rest of the post: this is a new domain for me, and thanks to this work, I will be able to do even better solutions in the future. You cannot know what is the right tool for the job, unless you know of the tool.

And finally a little disclaimer: Of course the situations you will face will all have their own restrictions and opportunities. This makes some techniques moot, but knowledge is always good. It's like neurons in your brain I guess. The more connections you've got, the smarter you will be no matter what.