One of the recurring themes that programming oriented bloggers post about is the suitability or lack of some programming language for solving problems. Two excellent examples ( and extremely informative posts in their own right) of this are: Why Why Functional Programming Matters Matters and a commentary on it, Measuring the power of programming languages. What is interesting to me is that none of the posts that I have read have every framed the discussion around the semantic distance between the solution and the capabilities of the language used to implement the solution. Bridging this distance is where most of the effort of development occurs. The closer the execution semantics of the implementation language are to the execution semantics of the solution the less implementation work is required. Reg Braithwaite, the author of the first example, has a number of wonderful examples of this, spread throughout his posts, in fact one could argue that semantic distance is one of the central issues of his intellectual life.

One of the clearest examples of semantic distance is in a wonderful paper, written by Paul Hudak, called Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity (beware the paper is only available in PostScript). This paper describes the results of an experiment comparing the suitability of different languages for creating prototypes of systems. One of the most interesting insights for me was the solution developed for the test prototype that needed to be built. The solution was based on a brilliant abstract and I realized that I could use it to solve a similar type problem I had and that I was not able to use Haskell in my solution. I could however imagine that I was able to use Haskell and so I did and developed a solution using Haskell. Now all I needed to do was translate this solution into the language I was using. To do this did not require that I write a badly implemented version of Haskell, rather I was able to quickly implemented a set of abstractions that matched those of my solution and that solved the problem. I used this technique because of my understanding of the concept of semantic distance and how I needed to overcome it to solve the problem. What I have since discovered is that many others use this technique as well.

I was a co-creator/developer of the streaming programming language OmniMark. On a number of occasions I have met former OmniMark programmers and a number of them had said that sometimes when they are faced with tough problems they work out a solution by pretending that they still had OmniMark. Once they have solved the problem using OmniMark they then implement a solution in the language they are using.

If you survey the over 5000 different languages and dialects that humans speak, you find that there is no universal set of equivalent semantics between them. This fact implies that there can never be a computer language which will always have the shortest semantic distance between itself and any solution. Therefore there never will be a universally best programming language. On the other hand, if you cannot use the best language for a solution you can always pretend you can. Once you have a solution then you can implement the solution in the language you have. Two follow on points to this: I hope you now see the value in learning other languages/semantics and that the downside is never being able to use the best language available for the problems you have to solve and always having to use this technique to bridge the semantic distances.