Monday, October 29, 2007

Polygot Programming analogy

I have been following a short email thread at work on Polygot programming (developing applications in more than one language). In its simplest form it is unlikely that an application contains a single language. Most applications involve some sort of XML :)

While reading the thread and a side note on construction I was struck by the thought that one could draw an analogy between a computer language and a construction material.

When putting together a car for example the designers choose materials that are suited to the job at hand. Each material chosen for its properties and application. A car made entirely using a material with a small set of properties (e.g. metal) would at the very least be very uncomfortable (steel tires).

With this thought it mind it is surprising that people continue to maintain the premise that a software application should be written in a single language. At best you get an explosion of code around the areas where the chosen language is not that good. At worst you see huge frameworks to get around the limitations.

Getting different languages to behave nicely together is not easy. Recent developments in leveraging runtime environments (JRuby, IronPython) make this interoperability simpler to manage but the problems rarely go away. The analogy with car manufacture works quite well - it is usually the interfaces between one material and the next where problems turn up.

Pushing the analogy even further it has been some time since carpenters have joined pieces of wood using wooden pegs preferring in the main to use screws. Steel screws are stronger than brass but brass is preferred for wooden boats because it resists the effects of sea water (as well as being more aesthetically pleasing).

Going back to automobile analogy the instrumentation systems use many different materials to delivery the required user interface, whilst the business end (engine) uses a more constrained list of materials (although in recent years this too has been growing). You could consider the instrumentation to be the equivalent of JavaScript on web applications whilst the engine corresponds to the back end systems (just a thought).

No comments: