Article: Paradigm based Polyglot Programming
Have you ever wondered why people talk about having “the right language for the right job”? Or why people talk about using more languages within the same system?
In this article, Sadek Drobi explains why you should consider mixing languages within you system. Sadek explains how different languages support different kinds of problems better (or worse) due to the nature of the language and the nature of the problem.
To dig deeper and to gain understanding of what polyglot programming can do for you, you find the article here: Paradigm based Polyglot Programming.
More on polyglot programming from Neal Ford...
Good stuff though...
Re: More on polyglot programming from Neal Ford...
Sure, Neal already wrote a lot of interesting stuff about Polyglot Programming as did Ola Bini and Martin Fowler too. However the focus of this article is more about considering paradigm of the language as the most important property of the programming language when doing domain analyses. The article describes an approach inspired by the referenced James Coplien's work on Multi Paradigm Design and Eric Evans' Domain Driven Design.
Thank you for the reference Jared.
Re: Fascinating subject!
Add to this another dimension
I want to point out two issues that may be missing from the discussion.
My thesis was actually the construction of PLOG, a logic programming language ala Prolog, but Object Oriented (OOPL). Here you have a combination.
To create an interpreter for that, we used C language plus Prolog to build a meta-interpreter (if you want to add to the mix).
Of course, there were two problems there: Find a way to blend PL and OO into the same language (Done by my professor) and a way to integrate both implementation languages into one product.
Some time ago I've heard about the idea in Java to include XML as a native type, that is the language will understand XML not as a product process but as a natural part of the language. Of course the result was not natural at all.
Having both paradigms in the same language is not an easy task, but if not included, you will need to work with round objects using a language for square ones!
That last issue is present all the time you want to work in a polyglot environment, impedance mismatch may appear too. So first thing to solve is how easily is to integrate two paradigms.
Now, DSLs can be used to solve problems in the actual domain of the problem. But you have always two spaces: the problem and the solution space. The problem one is where the client lives, and you may want to have a language in that domain to solve the problem from that perspective. But the solution of the problem requires you to work with technology, which is another domain. Thus you may need to use languages to work with those technologies, and the problem domain language is not appropriate. That is the second problem.
All that adds another dimension to the discussion: you need to know where are you working (space) and how to integrate all languages you use seamlessly.
What do you think?
William Martinez Pomares.
Re: Add to this another dimension
What I want to say is that seams do exist. There existence is at the domain level between sub-domains. We can not, and more importantly should not, ignore them. Considering the right seams can have its good effect on the integrity, extensibility and flexibility of the software.
Thanks for the supporting example about multi paradigm languages from your own experience.
Re: Add to this another dimension
I agree totally with you. That is actually what I'm trying to state above: You are working with several domains, some from the problem space and the others from the solution space. The seam does exist, and it is not difficult to ignore. A bad seam may cause malfunction or impedance mismatch.
William Martinez Pomares
Interesting subject put in words
Dominique De Vito
I can give my own examples about multi-paradigm languages. Let's cite OCaml (from ML family) for example:
- with some stream processing features too
Quite a few paradigms.
More people know its cousin: F# as F# is very strongly based on OCaml as Microsoft said itself.
One could see also :
- JoCaml and Acute for concurrency programming (partially sponsored by Microsoft Research) on top of OCaml.
- OCamlDuce is a merger between OCaml and CDuce, in order to introduire CDuce XML features into OCaml.
Similar languages in Microsoft world do exist : while F# puts functional features into C#, C-omega gives C# some XML features.
One key point here is type inference. It alleviates the burden for mixing paradigms into a single language.
It looks like Microsoft has quite well understood about the importance of type inference, as its main base language, C#, has inherited some type inference features too.
Another example of multi-paradigm stuff could be achieved through translators, just like Java-to-JS translator into GWT.
So, the battle is strong on both sides (polygot programming versus multi-paradigm), and I don't know which one is going to win. IMHO, while I strongly prefer multi-paradigm languages, I try to avoid "Highlander Fallacy" ("there can be ‘only one’") bad effects - here is an example.
I can't say also if having a common VM is a plus, or not for polygot programming. SUN and Microsoft, from my Java point of view, are promoting different sides:
- SUN looks like to promote polygot programming through JRuby, JPython and so on.
- Microsoft looks like to promote multi-paradigm languages through more research and development around C# with F#, C-omega and other languages.
Time will tell. Anyway, it's an interesting stuff, thanks for the post
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015