Alex is a Software Engineer working on Android development tools, especially Android Studio, at Google. His interests include Java, API design, OOP, IDEs and testing. Alex spends some of his spare time working on Open Source, blogging, writing technical articles, and speaking at international conferences. The opinions expressed here represent his own and not those of his employer. Alex is a DZone MVB and is not an employee of DZone and has posted 49 posts at DZone. You can read more from them at their website. View Full User Profile

Polyglot Programming: Flawed Dream?

09.19.2009
| 6557 views |
  • submit to reddit

I’ve been reading for some time various articles and blogs about Polyglot Programming, and the perception I got is there are two opposite views: the ones preaching it and the ones that tried and it didn’t work for them. IMHO, the points made by polyglot programming enthusiasts sound indeed pretty attractive, in theory. I haven’t seen any practical evidence yet to convince me this is a good idea.

BTW, I’m not referring to the typical web application written in Java, HTML, CSS and Javascript. I’m talking about using several “core” languages like Java, Groovy, Scala, or JRuby to write a single application. Although the idea itself sounds “cool,” I have doubts.

The right tool for the job?

The main point made by “polyglot programmers” is to “use the right tool for the job.” Sure!…it sounds great. IMHO, there are some hidden issues in this statement. First of all, to choose the right tool we need to have a deep understanding of the available tools *and* the problem itself.

In the case of programming languages, I think it is necessary to know a language beyond basic familiarity. IMHO, it is not enough to read a book and put together a couple of cute little exercises. Learning the syntax of a language is not enough, we need to learn what makes a particular language different. For example:

  • How mature is the language (and its libraries?) Who’s behind it?
  • Tool support: is there IDE support for X language, or do I have to use a text editor? What about debugging and refactoring?
  • Static typing vs. dynamic typing?
  • Paradigm: OOP? functional? hybrid?
  • Closures? Metaprogramming? insert-your-cool-feature-here?
  • Corner cases in a particular language
  • What about testing? are we using a separate language to write our tests?

I think we need to get the “feeling” and “style” of the language: I don’t want to write Java code in Groovy or Java-esque code in JRuby, just because I can. When using an alternative language, I’d want to use the features that makes such language a better choice.

Learning a programming language well enough takes a good amount of time and effort. It is too easy to “think” we know one and go ahead and write spaghetti code. The same applies to the paradigm behind the language. For example, Java is, IMHO, one of the simplest programming languages. Object-oriented programming has been around for many years (1960?) How many of you have seen horrible code in Java, written by “senior developers”?

Bottom line is, do we really have enough knowledge and experience to pick the *right* programming language?

Hidden costs

In an ideal world, we can spend as much time as we wish learning programming languages to choose the right one to solve the problem at hand. Unfortunately, we are constrained by both time and costs. I think the noble goal of polyglot programming can easily degenerate into:

  1. endless meetings, in an effort to agree which one is the *right* language, or
  2. take the decision lightly, for example: “concurrency in Java is hard, therefore we use a functional language”

Either way there is a risk of wasting both time and energy, either at the beginning or during the project life-cycle, which translates into wasted money.

Another hidden cost is the cost of integration. In a private conversation, my good friend Steven Herod brought up an excellent point:

Well, its the obvious problem, is the benefit of best of breed outweighed by the cost of integration?

You can see this even at the application level, is the best accounting system + the best CRM system + the best billing system better than a single system which does all functions, but not as well.

In most cases, you burn so much effort glueing things together that whatever productivity you get from a good tool is lost….

IMHO, we also need to have the following in mind:

  • how possible is to refactor code across multiple languages? do we have to perform a text-based, error-prone “find and replace”? (especially when mixing languages with static and dynamic typing)
  • is it hard to navigate through layers of code written in multiple languages?
  • how hard is to switch from one paradigm to another? (e.g. object-oriented and functional)
  • are any supporting materials necessary? (e.g. books, magazines, training classes – all of them cost $$)
  • how easy, fast and cost-effective (and actually possible) is to hire somebody that knows the languages and tools used in the project? are consultants needed?

As we all know, the most expensive part of a project is its maintenance. Polyglot programming supporters talk about the productivity gains when creating an application. Sure, this is great if we are all consultants that write applications, and leave them to the clients’ IT staff for maintenance. Till now, I haven’t heard about maintenance or bug fixing of a “polyglot” project. Writing code is always easier and more fun than maintaining it ;)

Success Stories?

I’d sincerely love to read more about success stories of polyglot programming. Not just how great polyglot programming is, but some explanations about:

  • project size/scope
  • team size: how many master programmers? how many journeymen? how many junior programmers? what about their background?
  • what programming languages were used? why?
  • who picked the programming languages used? how was the selection process?
  • what type of training was necessary (if any)?
  • tools used: any IDEs? text editors?
  • what were the benefits of polyglot programming? improved productivity? reduced costs? more fun?
  • how easy was to find answers when having technical issues?
  • agile or waterfall? or something else?
  • were more developers hired for the project? at which stage?
  • how was testing performed? what about continuous integration?

And no, pet projects and demos do not count.

Conclusion

I’m skeptical of polyglot programming. Although it sounds good in theory, there are factors that need to be taken in consideration before mixing several programming languages in a project. I’d like to learn more about success stories of real-world projects. Until then, supporting polyglot programming sounds more like cheer-leading to me :)

From http://alexruiz.developerblogs.com/

Published at DZone with permission of Alex Ruiz, author and DZone MVB.

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

Tags:

Comments

Scott Hickey replied on Sat, 2009/09/19 - 10:09am

Here is the first of four posts talking about my experience using Groovy on a large, mostly Java J2EE project. It directly address some of the issues you bring up.

Here is a link to a video presentation I gave a couple of years ago at the 2007 Groovy and Grails exchanged that talks in more detail about the this project, highlighting the actual business benefits gaining by using Groovy on this project. This presentation talks about many of your concerns and how things actually turned on our project.

At the time I gave this presentation, I saw somewhat the opposite of what you are describing. I saw lots of people bashing Groovy without ever actually trying it on a real project. I still see this with people who say they would never use Groovy because its too slow in micro-benchmarks. In the context of real project, a person will learn first hand that languages like Groovy and Python really shine because of their ability to integrate so easily with existing Java or C libraries.

When I was able to replace 150 lines of C or Java with 10 lines of Python or Groovy in some real project code, the light came on in a way that I certainly didn't expect. I think when a developer writes code where you begin to see important business functional "at a glance", it dramatically changes how the project plays out. I think it shows up quite dramatically in large projects where you have to come back and revisit functionality that might have been written 9-12 months earlier and isn't fresh.

fred jones replied on Sat, 2009/09/19 - 10:14am

Although the article doesn't contain evidence against polyglot programming, it does bring up a large number of valid concerns. 

In my experience, it is hard enough to get most programmers at my work to even 1) get a decent understanding of the technology stack and libraries that we use, and 2) learn Java in-depth.  I think if the average programmer at my work won't even do these two things, then introducing more complexity by having more languages is hopeless. I seriously doubt that many other development shops are that much different from mine.

I think that if you have Java programmers who write poor Java code, then things will get much worse when they write JRuby code.  Many individuals just aren't up to the task. For individuals, I think it's great to expand your range and learn other languages, but for projects and development teams, polyglot programming will just lead to trouble.

Oleg Timofeyev replied on Sat, 2009/09/19 - 4:29pm in response to: Scott Hickey

I would very much be interested in reading about your Groovy experience but your first link is missing. Would you be so kind to post that link one more time? Thanks.

Thomas Mueller replied on Sat, 2009/09/19 - 7:08pm

Most people are very good in only _one_ language (for me it's German). Only a small minority are fluent in more than two languages. Programming languages is similar. I don't _want_ to learn multiple programming languages. I'd rather spend my time learning one, but this one very well.

Then there is the cost of 'translation' (wrappers / adapters between programming languages) if you have multiple languages in the same project.

Robert Enyedi replied on Sun, 2009/09/20 - 8:27am

BTW, I’m not referring to the typical web application written in Java, HTML, CSS and Javascript.

To me this is also polyglot programming that leads to integration nightmares, but on a lower scale. HTML and JavaScript are low level languages best understood by a browser. Instead, I believe that as Web development will mature, the future will be the single language and technology that will gracefully hide the presentation languages and work at a higher level of abstraction. If you have ever worked with Google Web Toolkit or Eclipse Rich AJAX Platform, you'll know what I mean.

On a different note, I think that to best understand the values and shortcomings of polyglot programming is to imagine this scenario: you want to read a novel which contains the character descriptions in French, the description of landscapes and places in Spanish, the main flow of events in English and some technical topics in Japanese (that's like functional languages for procedural/OO developers). Even if you are fluent in all these human languages, you'd have to think: why?

Mike P(Okidoky) replied on Sun, 2009/09/20 - 12:24pm

Why is everyone so excited about Groovy this and Groovy that if Scala is better than Groovy?

Thomas Mueller replied on Sun, 2009/09/20 - 11:45pm

> Why is everyone so excited about Groovy

Mainly SpringSource is excited - because they bought the Groovy team.

Even the Groovy creator likes Scala: "if someone had shown me [Scala] back in 2003 I'd probably have never created Groovy."

Jose Maria Arranz replied on Mon, 2009/09/21 - 5:23am in response to: Scott Hickey

@Scott Hickey: When I was able to replace 150 lines of C or Java with 10 lines of Python or Groovy in some real project code

I have read this argument again and again to defend how good is "language X", most of the time, the real reason behind is: the new language X provides a built-in functionality, this functionality reduces the amount of source code in Y%, as anyone can do a custom made function to do the same, then the number of lines of code is reduced to (for example) 12 lines in Java, 2 lines more usually because the new "language X" has a syntax slightly more compact (for instance a closure is more compact than a Java annonymous class doing the same). Two lines of code are worth enough? Maybe, not for me...

In summary:

For me Groovy is interesting because is an scripting language based in Java syntax, not more, it may be interesting mixed with Java for a concrete part of your program if you need scripting, that is, bits of code going to change very frequently (or a sort of extensibility).

XML based languages are interesting for metaprogramming  if you need metaprograming, that is, changing how your program works changing bits of XML code without recompiling if you need this feature in production.

In other cases you are mixing languages with the same paradigms, doing the same with the same type of code (in spite of they may use different syntax)... bad idea.

1) "Hello my name is Jose"

2) "Hola mi nombre es Jose"

The first phrase is understood by everybody, not the second, the meaning of both is exactly the same, both languages are very different in syntax but most of linguistic constructions are the same because both share the same root (Indo-European). Spanish is slightly more verbose, is 15% more of characters "the argument" to change your preferred language? I don't think so.

For instance Scala is interesting because it provides to compiled languages a new paradigm for extensibility like traits

 

Armin Ehrenreich replied on Tue, 2009/09/22 - 3:01am in response to: Mike P(Okidoky)

Groovy can be used to do a quick and dirty script based on your Java knowledge and using your well known Java libs. It is almost Java or, to say it more precise, it is a dynamic version of Java. I think this is the main point of Groovy. And with Groovy you can play around with some exotic features but without having to memorize some totally new language. Scala is clearly much better designed than Groovy and much more powerful. But you have to invest a lot of time to learn it. If you know Scala well, I think you can use it also as a scripting language. So it can replace Java and Groovy together. But a lot of learning is necessary before that.

Scott Hickey replied on Tue, 2009/09/22 - 9:48am in response to: Scott Hickey

Sorry about the first broken link - my posts are located at http://defgroovy.com

Scott Hickey replied on Tue, 2009/09/22 - 10:43am in response to: Jose Maria Arranz

In my blog posts, I basically make the same argument about it not being worth it if the scope is small - i.e. 12 lines of Java with two lines of Groovy. I think this logic applies whether considering a language or library.

However, on the largest project on I worked on using Groovy, we have about 50,000 SLOC in Groovy. Over that much business logic, the impact was significant.

For myself, the biggest benefit I anticipated before I had actually used Groovy was the readability of the code involving BigDecimals. Writing functions helps a little but not much it this case - the math was complicated and the subject matter experts reviewing the code definitely didn't want to see .add() and .multiply(). What I learned after being on the project for a while was that the sum of the benefits from using Groovy was greater than the parts. The readability of BigDecimal, native operations on collections, removing type declarations, optional exception handling, etc... all contributed to a code base that was amazingly easy to read and maintain. I can't emphasize enough how much I didn't expect that to happen - and I'm a fan of writing small functions and trying to get my Java code to reflect the domain.

I think the best thing a developer can do is take some non-trivial piece of functionality - at least 300 SLOC of Java - and rewrite it in whatever language you think is going to help you. The whole point of using a different language is that there should be some benefit realized by doing so. When we did this in our project, all of the other arguments went to wayside; the difference was dramatic for our domain .

Scott Hickey replied on Tue, 2009/09/22 - 12:03pm in response to: Thomas Mueller

Groovy code and Scala code are going to look completely different. They have different sweet spots, IMHO.

The people who have used dynamic languages with great success tend to be the ones who are really excited about using Groovy, JRuby and Jython. I can't speak for languages other Groovy, but I know there are plenty of success stories in banking and finance that don't involved G2One/SpringSource.

I am convinced that no one will be able to devise the "killer" argument to convince any Java programmer that using a dynamic language can be useful. But the enthusiasm is real because it is exciting to see how a code base transforms itself into something wonderful that you know you never could have created in Java. Personally, I think it has to experienced over time in the course of real project work before it hits home. The people who use Wicket, Tapestry and SpringMVC have same enthusiasm when they compare their new experiences to using Struts 1.0.

Mark Unknown replied on Tue, 2009/09/22 - 9:04pm

Scott,

 I think it would help to explain more about the specific application. J2EE is just too broad. 

 I build componetized apps with things like Eclipse RCP and RAP and GWT and Hibernate and OSGi.  I don't build "webapps". My apps might have a browser UI.  How can i use Groovy (or Scala) in my the apps?  I know how i can use it for builds (ie GANT) and scripting other tooling type functionality. I don't need to provide a way for users to "script" the app like VBA does.

Scott Hickey replied on Thu, 2009/09/24 - 6:56am in response to: Mark Unknown

Mark, In various links to video and slide decks on my blog, http://defgroovy.com, I go into a lot more detail about the project.

The quick version is that this was large group insurance sales application. The GUI was Eclipse RCP talking to WebSphere on the server. Groovy was used to build the calculation engine that calculates the premium to charge. There might be literally hundreds of the thousands of individual intermediate calculations that take place to generate the rate. By the time we finished, 99% of the sold business could be calculated in less that one second per group.

The engine was jarred up, wrapped by in an EJB and deployed just like any other Java EJB. The public API had static types declared and devs could use code-completion from RAD/Eclipse just like any other library. Our Groovy rate engine lived peaceably along side other libraries like Hibernate that do byte-code generation; no jar hell. Internal to our component, we used Spring for DI and exception handling to keep the code noise to a minimum. The code was readable enough that both Java devs and the insurance actuaries themselves could maintain the code. The code base was about 25,000 SLOC of business logic and the other 25,000 SLOC was either unit test code or the custom integration/regression test framework we built. We used Ant for the builds and ran JUnit and Cobertura from Ant.

This application definitely was not using Groovy to "script" anything. The actuaries that make changes follow the same processes that normal devs do for version control and testing.

Comment viewing options

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