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.

...and a very good abstract on the topic. Developers definitely need to take more time choosing the right tool*S* for the job*S*. I am however a bit skeptical on the low weight given to the Team Members’ skills factor! I agree that very often, people are just too lazy to even consider learning a new language/skill. But at the same time, when does it make economical sense for a project to grind to a halt so that a new language can be introduced?

Also, what about the community of users/usages built with time around programming languages? I am for example curious to hear whether the case of javascript was excluded on purpose or was just an oversight.

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.

@Olivier: Javascript and other languages that wasn't mentioned here haven't been ignored. I just mentioned in the article few examples and the list is far from being exhaustive. Yet javascript properties are interesting to study and consider.

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.

@William : The integration of several languages/paradigm on the same project is in my opinion more domain bound than technical. What I mean is, and as you mentioned, the problem exists even if you use a multi paradigm language. The technical integration of several paradigms in a multi paradigm language does not take into account your specific domain or problem.

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.

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.

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

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.