Maxim has posted 5 posts at DZone. View Full User Profile

To Polyglot Or Not To Polyglot?

  • submit to reddit
Andres Almiray in his recent post How many times are we going to "kill" Java is advocating "polyglot programming". I think that the topic is not very simple and it may depend on the situation, environment, developer skills, number of people in the development team etc. We are real developers and need to make real decisions on what to use or not. So, here I would like to suggest everybody to post their opinions and real uses cases where they consider polyglot programming to be good or bad. Please be critical and honest. I'll start with my use case:

I do quite a lot of Swing-based application programming with a remote backend. On the other hand there are a lot of projects using Java on the server side and HTML, JavaScript on the client. When I compare debugging possibilities for both cases I see a very big advantage of the usage of the same language on the client and server. E.g. debugging of Swing application which calls some remote Java method I can do quite easily because:

1. I can do step-by step debugging from client code to server code and back in a single debugging session (server must be executed in the same process)

2. I can use only one IDE for debugging instead of bunch (Firebug, Eclipse or whatever)

3. Mapping between variables is transparent because I have Java at both sides! I don't have to think which Java type is mapped to which in JSON or in some Webservice

Personally I didn't work with Groovy + Scala + Whatever +Java mix programs but I suppose that similar problems with debugging could appear.

Your opinions, use cases guys?

(I didn't posted it as a comment to Andreas's post because I'd like to stress attention on use cases.)

confused.jpg7.24 KB
Published at DZone with permission of its author, Maxim Zakharenkov.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jesper Nordenberg replied on Thu, 2008/06/05 - 5:38am

If the IDE supports all programming languages you use and they all run on the JVM, there is no difference debugging a multi-language app compared to a 100% Java app.

Mark Thornton replied on Thu, 2008/06/05 - 5:46am in response to: Jesper Nordenberg

Provided of course that the developer(s) are also comfortable with all the languages involved. Otherwise you have virtual Here be dragons signs erected at the boundaries.

Maxim Zakharenkov replied on Thu, 2008/06/05 - 5:57am in response to: Jesper Nordenberg

@Jesper - Good point about "all run on the JVM". How would you estimated IDE rediness for that? In need to develop porojects just now. How long should I wait? It is also interesting how stack traces will look like if I use language mix?

Jesper Nordenberg replied on Thu, 2008/06/05 - 6:32am

I only use two languages on the JVM: Java and Scala (I don't wanna give up static typing). The Eclipse Scala plugin is pretty good now (inferior to the Eclipse Java support though) and the latest version should support mixing Java and Scala source in the same project (previously you needed separate projects for that), but I haven't tried it yet. Stepping between Java and Scala code in the debugger works fine.

As for stack trace entries, there's nothing Java specific about them, they just contain class and method name, source file and line number, so they look fine with any language which compiles to normal JVM class methods.

Maxim Zakharenkov replied on Thu, 2008/06/05 - 6:36am

How about automated cross-language code refactoring?

Jesper Nordenberg replied on Thu, 2008/06/05 - 7:03am

Refactoring is not supported in the Scala plugin, but hopefully it will be integrated with the Eclipse Java refactoring when it's implemented.

Maxim Zakharenkov replied on Thu, 2008/06/05 - 8:00am in response to: Jesper Nordenberg

Why you don't use just Scala only?

Serge Bureau replied on Thu, 2008/06/05 - 8:00am

Definitely AGAINST polyglot programming.


First it is not needed, second it is a maintenance nightmare, and very difficult to apply change.

It is very brittle.


A good example of this horror is Ajax.

 Groovy is an exception to me, it is an extension of Java, so I am not really leaving Java and the mix and tools are pretty transparent.  And it brings scripting as a bonus. So why should I need anything else ?

Maxim Zakharenkov replied on Thu, 2008/06/05 - 8:23am in response to: Serge Bureau

@Serge - You know, polyglot programming and multiple languages has a one big plus - It creates more job opportunities for developers. Imagine we had only one language and platform for everything. Would you be happy? :) On the other hand these "job opportunities" make lower quality of an average developer.

Jesper Nordenberg replied on Thu, 2008/06/05 - 8:23am

There are different reasons why it's not possible to use only Scala in a project (even though I would like to):

  • There is an existing Java code base that needs to be maintained
  • Political reasons, Java might be the only language allowed in a project
  • The IDE support is not as good as for Java
When migrating code to Scala it's really nice to be able to seamlessly mix Java and Scala source in the same project.

Serge Bureau replied on Thu, 2008/06/05 - 8:55am in response to: Maxim Zakharenkov



I should have been more precise.


I have nothing against other languages (maybe some of them ;-) ), but polyglot on the same project  on the same project is a BIG mistake.


Your reasonning is the same as not documenting and UnitTest so we can have  a job forever, very wrong ! 

Serge Bureau replied on Thu, 2008/06/05 - 8:57am in response to: Jesper Nordenberg

To me Scala is totally alien to Java, nothing ressemble at all. So it is not a mix but a mess.


Use one or the other. But avoid mixing. 

Maxim Zakharenkov replied on Thu, 2008/06/05 - 10:55am in response to: Jesper Nordenberg

Short summary from our discussion:

1. It seems like there is no such IDE yet (See quotation below)

[quote=jn45229]If the IDE supports all programming languages you use and they all run on the JVM, there is no difference debugging a multi-language app compared to a 100% Java app.[/quote]

2. Re-factoring is also not fully supported (I suppose that in general it is even unsolvable with untyped languages)

3. Understanding of variable mapping between different languages can be a problem

4. Avoid language mixing! If you use some language other than Java which compiles into JVM byte-code try to use only this language. Otherwise you will have troubles with maintenance.

So, it makes me think that polyglot programming in one project is not very good practice.

Are there any other opinions, case studies?

Philipp dsfgsdf replied on Thu, 2008/06/05 - 1:53pm

I have been a Java developer for quite a while and have been working with .NET for almost one year now. One day I had to fix a an apparent bug in another component. I opened the project and... guess what happened! I expected a C# project... but it was Visual Basic... totally unreadable to me. The guy who developed that component left the company a few years ago.

I would never switch to multiple language programming deliberately because you can end up in a mess like the one I mentioned above.

On the other hand, using special languages for special purposes could make sense in some cases. E.g. using Groovy for rapid prototyping.



Mark Haniford replied on Thu, 2008/06/05 - 4:13pm in response to: Philipp dsfgsdf

I'm a C# guy myself too, but reading VB.NET shouldn't be that much of stretch - it's not like going from Java to Scala. On the other hand, I wouldn't recommend polygot programming on the same either - especially when languages like C# and VB.NET are just really minor surface syntaxes skinned on top of basically the same core language.

That said, I could see using F# for a numerical library or Boo for creating a DSL. But I do see your point when it comes to C# and VB.NET

Philipp dsfgsdf replied on Thu, 2008/06/05 - 4:58pm in response to: Mark Haniford

Reading VB.NET is of course possible but I was really shocked when I saw it first. It reminded me the old gwbasic hacks in school. My point is that especially if your team is of a certain size and a specialist in language xy leaves the company, polyglot programming makes you much less productive. This is obviously something we all should avoid.

Steven Baker replied on Thu, 2008/06/05 - 6:13pm

I'm working on a project at my work and it has many communication layers between Java servers and C servers.

It's been years since I've done C coding, so natuarlly the time to develop and debug between these is very VERY long.

If only they had both been Java... 

George Jempty replied on Thu, 2008/06/05 - 7:15pm

It's a matter of the right tool for the job.

I've been away from Java for 1.5 years working primarily with PHP in the meantime. I'm currently developing on an embedded device over which I have no control as to what software is installed. The version of SQLite that is installed is v3, but the built-in PHP module only supports SQLite2. The solution: TCL, of all things, with it's outstanding bindings for SQLite, and support that goes in the other direction as well, e.g. the ability to set an SQLite "mode" so that output is generated as a TCL list.

Again I say, it's a matter of the right tool for the job. Not the fashionable tool, not the only tool me and/or other co-developers have ever used. The right tool.

Steven Baker replied on Thu, 2008/06/05 - 8:23pm

George, I think your example comes down to the right tool being pretty much the only decent tool.

Most projects have some flexibility in which we can choose which techonologies to use.

Nick Brown replied on Thu, 2008/06/05 - 8:30pm in response to: Mark Thornton

That sounds like an argument for using multiple languages on one project to me. If certain developers keep away from my code out of fear of dragons, then I won't have to worry about them changing something without asking me, then breaking it, and then leaving me to field the blame when nothing works.

On a more serious note, on a large project it should not be neccessary for each developer to understand every technology evey other developer is using. If the UI is developer using some UI library that the backend developers are not familiar with, you have the same issue as you would if they were using a different language.

Steven Baker replied on Thu, 2008/06/05 - 9:35pm

nick, i really hope that first part was not serious in the slightest, or you better put on your fire retardant suit cause your gonna get flamed!

Peter Thomas replied on Fri, 2008/06/06 - 12:45am

Never really used the term "polyglot" until now, but have a look at this picture:

Would it be correct to say that the left side of the picture is "polyglot"? I'm completely for the other side because yes: it is far easier to maintain & being able to debug seamlessly is huge.

The full blog post is here.


Maxim Zakharenkov replied on Fri, 2008/06/06 - 3:15am

@Peter  - The diagram looks very promising :) I'll probably take a look at Wicket.

It also worth to mention our best friends - XML based languages for ANT, Maven and Spring.

Nick Brown replied on Fri, 2008/06/06 - 7:08am in response to: Steven Baker

That would probably be why I began my second paragraph with "on a more serious note"...

mike replied on Fri, 2008/06/06 - 4:19pm

One thing to watch out for is the 'right tool for the job' argument. Too often this is used when the 'right' tool is subjective and or comes with penalities. We have people on our project wanting to use Groovy, JRuby, etc, (in our already too-diverse project) and they insist it's the 'right' tool. If you press them, you find out that A) they just want to use it because they think it's cool; and B) they have to seek justifications for why it's the right tool. There are certainly places where you must mix languages, but if the reasons for it being the 'right' tool aren't obvious and overwhelming then a red flag is raised in my book. Too often their justifications boil down to things like "I can do this one task in 5 lines versus 20" or "I can do this one task in 10 minutes versus 30". To me, that doesn't make it the 'right' tool. Especially if you're only doing a few simple tasks. The flip side (that they often ignore) is that comes with "yes, but now its going to take you 3 days to get up to speed on this new language and its going to take you several lines of code and xml and configuration and other supporting files to integrate this new thing with our extisting framework."  I'd rather it take a few more lines and/or a few more minutes and have everything homogenous so this project can be maintained for another 10 years than save a few lines of code or a few minutes. Yes, use the right tool for the job, it just better be the right tool. A pneumatic nailer might be the right tool when building a deck, but if I'm just replacing a few boards, the expense of the buying the tool isn't justified if I already have a hammer.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.