The Right Tool for the Job

Among the coder communities on the net, one topic is always good for a bar fight: it's arguing over which programming languages are the best at any given task. For the most vocal commenters the answer is obvious: "C! Java! Perl! Ruby! Haskell!" They claim that whatever task you're trying to perform absolutely needs their features, and that you'd be a fool to go without them. What they don't realize — or if they do, they don't mention it — is that the programming language isn't the end-all-be-all of the software development story.

For my part, I think that the advantage gained from a given language is determined by and large by how well its own innate model fits with the models that the programmers themselves build with the language. Our abstractions and the mechanisms we use to express the problem inside the language itself are by and large more important than the actual syntax and semantics of the language itself. Meta-language determines the expressiveness and power of the system.

Language selection is important primarily because of the knock-on effects of the language’s features and what abstractions they make easy or hard to build. It is difficult to write purely functional programs in C for example, and if your problem domain lends itself well to functional programming you'd be better off with a different choice of tools. On the flip side, in lots of domains the common languages such as C++ and Java do just fine. It's possible to build the correct abstractions in them, and while the programmers may be able to avoid some syntactic itches by using a different language, they are not held back from solving the problem. As long as you're able to express the right building blocks, your implementation language can fade to the background.

If you like what I write, you can subscribe to my mailing list to get new posts in your inbox: