CodeBlab

Managers often are confronted with a need to choose a programing language. Usually they ask themselves questions like: “How simple is it to learn language X?”, “Do our coders like to switch to language X?”, “How well does our IDE support language X?”, “How well known is language X?”

These questions, however, might not be all that relevant. While a Turing Machine can be used to code graphic animations, probably a more abstract and domain specific language like Processing would be more productive (and fun). However a Turing Machine might score better on the questions above. The more relevant questions for selecting a language focus on two terms domain and abstraction. I won’t try to explain why, or even define these two terms (click the link, Luke). Suffice it to state that: Experienced coders use more abstract features to make more compact code and, thus, be more productive. Domain specialists use more domain specific features to code quicker and, thus, be more productive.

One could be forgiven the mistake of thinking that the more abstract a language is the less domain specific, and vice versa. A random counter example is PostScript, a powerful, abstract, concatenative language, used almost exclusively in the domain of printers.

So if you employ a domain specialist (count your blessings and) choose a domain specific language. If you employ a code wizard (count your blessings and) choose an abstract language. About the worst you can do, is pick a abstract, general-purpose, multi-paradigm language like Python for a mathematician to code math models. Best case this will eventually lead to a huge and clunky library stack like Python(x,y), that dictates every other aspect of all the code that interfaces with it. Very soon, the lack of flexibility will drive everybody back to using a spreadsheet for their modeling. Maybe a better choice would be a language like R, or indeed that spreadsheet.