What is in *your* language toolkit?

The way we solve problems, heck, the way we think about problems, is based upon the tools that we use. Phrased somewhat simply — “If all you have is a hammer, everything looks like a nail”.

Mind you, this gets particularly egregious in the world of software development. Your run-of-the-mill #CowboyDeveloper learns Java (or C++, or whatever), and then spends the rest of their life writing Java in Ruby syntax, or golang syntax, or whatever. Mind you, the really bad part here is not that they haven’t figured out the semantics of the new language, it is that they genuinely believe that there is no difference, that programming languages are just different syntaxes, that notation doesn’t matter.

And that, my friends, is a problem. As Kenneth Iverson pointed out in 1979, Notation Matters. If you translate the words from English to Telugu, you might, maybe, make some sense, but only barely. Getting anything beyond the bare minimum of information across will be remarkably hard. Similarly, the syntax one uses in programming languages is deeply emblematic of the underlying semantics — learning the syntax is a far cry from mastering the implications of the syntax (i.e., the underlying semantics).

That said, the first step here is to understand, and appreciate that there is an underlying difference, that the notation used matters, that the way we think about the problem will change based upon the specific language that we are using.
Languages are optimized for specific use-cases. Yes, you can pretty much rewrite your code in any language as long as it is Turing-complete, but then, hey, you could also write your code in Assembler (note: I wouldn’t recommend it for most cases). The questions you have to ask yourself are

1. 1. How easy is it to express the constructs in my problem? Note, this isn’t just the immediate problem at hand, but also those arising from subsequent analysis, generalization, specialization, etc.
2. 2. Can I express my solution with economy? Do I have to generate tons of boilerplate (cough, Java, cough)?
3. 3. Can my solutions be used elsewhere? Portability, reusability, maintainability, all of these are relevant from the perspective of the lifecycle of the code

The answers that you get will vary based not just on the problem, but on your level of experience in the problem’s domain, the languages that you have used, the team you are working with, the customer that will use the product, your organization, and much much more (I never said this was easy!).
That said, if you’re not thinking of these at some level, you probably need to level up 😇