Polyglot Programming: Flawed Dream?

by Алекс Руис on September 18, 2009

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.


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 :)

Update: This post has been published at Javalobby.

(Image taken from marimoon’s flickr stream under the creative commons license)

{ 30 comments… read them below or add one }

Cedric September 18, 2009 at 9:57 am

Couldn’t agree with you more.

Polyglot programming is a fallacy. The right tool for the job is not multiple languages, it’s one language flexible and rich enough to solve 90% of your needs.


Alex Ruiz September 18, 2009 at 10:20 am

Thanks Cedric :)

I particularly like Google’s approach, one language (Java) and multiple environments/run-times: GWT, Android and App Engine.



Richard Osbaldeston September 18, 2009 at 10:23 am

I think calling Andriod, App Engine (and even GWT in some respects) Java is a little tenuous.


Andrew Rodland September 19, 2009 at 2:29 am

Google uses a lot more languages than Java — Python and C++ come to mind, and I’m sure some of the infrastructure bits in the background use a good deal of C. It’s just that they’re brought together in a loose-coupling sort of way via interfaces like MapReduce, GFS, and JSON REST, instead of having all of the languages coexist in one runtime and calling each other directly.


Richard Osbaldeston September 18, 2009 at 10:36 am

Me too I think some of the ideas are valuable but the practise dubious. As much as developers love to be control freaks using you have to keep using every language often enough to stay relevant. Just keeping up with Java platform and it frameworks exhausts me.

How many developers get that much of a choice in the languages used? only a few CTOs and consultants have those kinds of advantages.

That said keeping your head down and only networking in small similar-minded circles isn’t healthy. It’s worth your while expanding your horizons a bit and seeing what make other languages and new frameworks so valuable. Really great ideas will no doubt get ported to your language of choice at some point.


Alex Ruiz September 18, 2009 at 10:52 am

Hey Richard!

I agree with all your thoughts. It is not easy to keep up with one language and its libraries/frameworks. At the same time, like you said, we need to explore what’s out there and not limit ourselves with our favorite tool.

Thanks! :)


Developer Dude September 18, 2009 at 1:20 pm

IMO, integration should be moved to the top of the stack. The second (or third, fourth, etc.) language must integrate well (easily, without serious disadvantages) with the other/primary/legacy/core languages, or the rest of the possible advantages are not usually worth the hassle.

Almost a decade ago I had to work with modules in Obj. Pascal, C++, and Java on two different OSes (Mac OS9/OSX, Windows), with two different hardware platforms (Intel, Motorola) with four (or was it five?) different compilers/IDEs (Metrowerks, Borland, DevStudio, Javac/et. al.). Integration (different calling sigs, little/big endian, different OSes, etc.) was enough of a nightmare that we avoided it at all costs.

A lot of that has gone away, and I love working in pure Java and not worrying about such things.

My point is, unless the language was well integrated into the Java world (e.g., JPython, Scala, etc.), it is a non-starter with me.

Beyond that, I don’t go off to learn a new language every time one comes out. I concentrate on getting better with Java – for me, there is plenty left to learn there (and learn how to do it well) with the new APIs/frameworks and other new language features (especially concurrency).

Ruby, Groovy, Python, etc., may all be real popular in articles, google searches, etc., but if you go search job postings they still fall way behind Java and C++, so far that they aren’t even on the radar. Plus I have never liked dynamically typed languages.

I am thinking about picking up Scala to learn more about concurrency, but even there the language will have to provide an easier, more understandable, more robust, more elegant methodology for solving the problem than Java for me to adopt it.

I’ll let the braniacs sort out the other languages and see which ones become popular in a decade or so.


Alex Ruiz September 18, 2009 at 3:03 pm

Thanks Developer Dude! I don’t have anything to add except that I completely agree with your points of view :)



bwtaylor September 18, 2009 at 1:33 pm

I’ll bite. We use a bit of polyglot programming with java and groovy. We run a mission critical app for our business. Most of our “main app” is written in java, and we use groovy to write scripts to solve production issues with it like data migrations and one off requests. Also for some build automations. We also have one “side app” written in grails, and are likely to do more of these using grails, for example an admin console. We try not to make individual modules out of multiple languages. A developer is not likely to edit groovy one minute and java the next. More likely, they’d open a project in their IDE that’s all groovy and uses jars we produce from our java side.

Our team size is 8 developers, including one architect (me), a three senior devs, three intermediates, and one junior developer. We also have a sysadmin who writes code occasionally (he started the grails app). I generally have final say as architect on whether something is allowed. I’m encouraging more use of groovy/grails, but I’m trying to keep it “modularized”: first we did build scripts, then production scripts, then wholely separate apps. Next we’ll allow it in the web app layer over our service layer on an app by app basis. We didn’t have any special training, but we all have a bunch of groovy books lying around.

We don’t constrain developers regarding IDEs. We have folks using Eclipse, IntelliJ, Netbeans, and text editors, and switching between them if they feel like it. We all find Eclipse annoying to do groovy in, by the way.

If you are doing java, you are probably already doing polyglot programming between java and XML. We view groovy as better than XML and would prefer all XML contstructs to be replaced by it. We write java for our services, model, and integration layers. We use groovy to script these and we are starting to open it up for the presentation side. When we do this, we take our main java code, jar it up, and provide it as a dependency to the groovy code. The big benefit here is that groovy’s fluid is simply more productive and agile for certain tasks. For most things in the backend though, we still like the speed and tooling of java.

For example, last night we had an issue with a slow web service call to another system. It was causing our UI to throw a timeout error. Fixing the root cause will require an overhaul of this web service call. We wrote a groovy script to incrementally move the large data sets in question into our cache. We’ve added a cron job to run this script daily. This took a few hours of work.

We try to use lean software development, but I don’t see much connection between methodology and languages. We don’t seem to have much issue with language technical issues.

We have extensive automated testing. We do more integration testing than most do, and probably less true unit testing. We have extensive UI testing and are trying to make QA about producing and managing these rather than playing clickety-click in our app. We use selenium for this. We use hudson for continuous integration. It works fine with ant, ant+groovy, gant, and maven, which at any given time we’re using some mix of.


Alex Ruiz September 18, 2009 at 3:02 pm

Thanks for sharing your experience :)

I think combining Java and Groovy is the simplest and safest path for polyglot programming, due to the proximity in syntax between two languages (by design.) On top of that, tool support for Groovy has improved a lot (in Netbeans and IntelliJ.)

I’d say that the way you have chosen how to use Java and Groovy is pretty well-thought. If I understood you correctly, core code is written in Java and glued together with Groovy. I imagine that maintenance is a lot easier since the core is in Java (static typing, excellent IDEs, etc.) Have you noticed any drawbacks of using a dynamic language like Groovy? (e.g. refactoring, debugging, etc.)

As I side note, I like your approach of extensive integration and functional testing. IMHO, those are the ones that can really tell you an application does what is expected to do.



bwtaylor September 19, 2009 at 11:59 am

Well, I do think that dynamic languages sacrifice a lot for their elegant syntax. Performance, tooling, and compile time problem prevention are all big sacrifices. This is one reason why I think scala will be huge. It seems to have proven that you can have elegance and strong static typing.


Sai Venkat September 18, 2009 at 2:09 pm

I agree with a lot of your points on problems with polyglot programming. It gives an interesting perspective on the practical working of polyglot programming. But still there are instances which I personally feel are good places where polyglotism (Not sure if there is a word like that :) will be useful.

A lot of projects even if they are developed in Java or .Net use rake to build or capistrano for deployment to production. Not a pure polyglot example but still I think it a good example of using right language for right job. Also I have seen application in production where the front end was developed in rails and the back end being data operation intensive was developed in Clojure. A lot of applications on the social networking web are polyglot like twitter with rails frontend and services built on other languages (Think probably C, Java and Scala but not sure). Facebook chat where I think web part is in php and chat is handled by Erlang…

Also in my view having functional tests in a different language probably dynamic one when development language is different is also a kind of polyglot. Let me know your thoughts.


Alex Ruiz September 18, 2009 at 3:07 pm


Your example of using alternative languages for build scripts is valid. But I was referring more to the other examples you mentioned, like Facebook and Twitter. I’d love to hear pros and cons on the technical decisions they made.

Probably testing can be treated different, since they are somewhat separated from the production code. The idea of using a dynamic language to write tests sounds pretty attractive to me. Unfortunately I haven’t had the chance to try it out yet. I’m thinking for that task I’d choose Groovy. We’ll love to hear more of your experiences!



dm3 September 19, 2009 at 2:56 am

I tried to write unit tests in Groovy on a medium-sized project done in Java. It doesn’t bring any huge advantages – test set up merely gets less verbose. On the other hand, you lose the ability to refactor tests together with your production code which is a big impediment. Anyway, I started to dislike dynamically typed languages after this experience.
I believe Scala could do a great job acting as Java companion on big projects when the IDE support gets up to date.


Jose Fernandez September 18, 2009 at 4:38 pm

I’m glad someone wrote about this topic. With all the polyglottery I’ve seen lately I was starting to wonder how much of it originated from pet projects and how much came from under a corporate umbrella. Software to me is all about maintenance. It doesn’t matter how cool or hip an application is if no one can maintain it.

I think successful implementation depends mostly on team size and to what degree they share work. If it is a small team – say 4 or 5 people – and only one person worked on the component that uses the “different” language, if they became unavailable it could be catastrophic.

If its a large team and 4-5+ people have worked in the language and/or around the component, or a smaller team with everyone dipping into all parts of the project, then filling those shoes becomes easier.


Jean-Francois Poilpret September 18, 2009 at 9:31 pm

I generally agree with your view, Alex, and I am also yet to see practical real-life examples.

Theory is interesting only if it can be put into practice!

Although I hadn’t have the chance to practice “polyglotism” in projects, I already had the thought of some projects where it *could* possibly have helped (in theory!).

In particular, there are some languages (Scala is a very good example) which allow you define a DSL that actually IS embedded in that language (without looking complex to end users). The DSL if made sufficiently simple, can be let to some system “administrators” to configure some complex business rules in the system, in a simple, safe , and performant way. This is safe in the case of Scala because you would have compilation of the business rules before they can be deployed. Other plus points are the configurability of the application at lower cost (otherwise, creating new rules or mdoifying existing rules would require new Java developments).

In such case, for development and maintenance, we can always have 1 or 2 scala “specialists” while the rest of the team is made of only Java developers. But that would be viable only for project team sizes of over 10 members I think.

But that was just a thought, no real practice here.

On the other hand, using other languages for other aspects of project lifecycle (eg tests, build, deployment) definitly makes sense, as mentioned in some comments.


Alex Ruiz September 22, 2009 at 5:12 am

Hey Jean-Francois!

Yep, I agree about using other languages in the project life-cycle. As ugly XML is, we are already using it in Ant or Maven. I admit I’m looking forward to replace XML with Groovy for building my projects sometime in the future :)



Dean Wampler September 19, 2009 at 6:53 am

It’s good to post skeptical views on this topic. In the talk I did at last year’s QConSF (InfoQ just posted the video) I cite specific examples where it has been used successfully. Emacs and Android are two good examples. I’m doing this talk again next month at StrangeLoop in St. Louis. The one thing I intend to emphasize more this time is the set of potential disadvantages and gotchas. Of course, there is no silver bullet.


Alex Ruiz September 22, 2009 at 5:13 am

Thanks Dean for stopping by!

I’ll be watching your presentation shorty :)



Alex Miller September 19, 2009 at 7:00 am

I wrote a test framework a couple years ago that was a mixture of Java and Groovy. The Java code was the performance-sensitive system under test. The Groovy code provided the “use case scripting” and test harness to actually write a test case. Using Groovy for the scripting allowed me to make the tests much simpler and DSL-ish, time things by passing closures, etc. It was a very nice mix.

There is definitely a good set of people now using Clojure to write Hadoop jobs. I could totally see writing some statistics or analysis code in Scala or Clojure but dropping it into a business app.

This kind of thing makes perfect sense I think where there is a natural seam in the application, especially where the two parts of the code are changing at different rates, have naturally different developer communities, etc.


Dane Morgridge September 19, 2009 at 7:55 am

I think there are really 2 kinds of scenarios you have to look at here. I personally consider myself a polyglot programmer since I personally know and can work with multiple languages. I think that using multiple languages in a single project is generally not a good idea, unless you have no choice. For example, I am working on a project that requires a mobile application on multuple platforms and a desktop application, again on mutiple platforms and a web service to sync data between the 2.

In an instance such as this, you have no choice. You have to use Objective-C for iPhone (or .net now that monotouch is out), Java for Android and Blackberry, and either C++ or C# for Windows Mobile. That’s a minumum of 3 languages on it’s own. Then when it comes to the desktop apps there are ways to do it all in one, but there is still the likelyhood that the mac app would get written in Objective-C and the windows app in either C++ or C#. Then you have the web service which I would either do in Java or C#, depending on the OS it was going to be hosted on.

While I think it is a good idea to have multiple developers that can specialize in each area, it is also very helpful to have developers who can pick up any peice and either write new code or fix bugs in existing code.

I am personally of the feeling that the “right tool for the job” thinking is great in theory and in practice. I think the real problem lies in the fact that alot of people who try the polyglot concept don’t have the skills/talent necessary to pull it off without it ending up costing more in the long run.

In short, I do agree with your post in that the points you share do apply to a lot of people attempting to be polyglot. I also disagree because the points don’t apply in every case and there are some people out there you can pull it off and do it well. Ted Neward comes to mind.


Jeff Davis September 19, 2009 at 8:32 am

For a success story, how about UNIX and UNIX-like operating systems?

* lots of developers
* successful result
* long time
* lots of languages, like C, sh, bash, perl, python just to make a given UNIX-like system work at all
* applications on top of UNIX can be written in almost any language

So, the interesting question is not whether polyglot programming is useful; I think that is clear that the answer is “yes”. The interesting question is what APIs should exist between languages.

In UNIX, the API is largely the POSIX filesytem layer, along with the use of standard input/output (and other forms of IPC like unix sockets and network sockets). That’s not a particularly rich API, but it gets the job done.

I think what you’re referring to when you say polyglot programming is some kind of object passing system where you send objects from one language to another and the other language is supposed to “understand” the object from the first language. I think that kind of API rightly deserves some skepticism and criticism. Languages are different, and it’s hard to make some kind of magic substitute for clearly defined expectations between two programs.


Jordi September 19, 2009 at 8:35 am

I know this probably doesn’t count, but I’m building a Brain-Computer Interfacing application in a scientific setting. I guess it can be considered more of a prototype than a really polished application.

There are a couple of separate components (data acquisition, feature extraction and classification, visual stimulation, the controlled application, and an integration/main module). Conceptually we view the BCI as one application, but all of these components are actually separate programs that communicate using TCP. This makes it easy to use different languages on the different components. We have the most expertise on Matlab, so this is generally the language of choice. However, it is fairly slow and doesn’t really support threading (amongst other downsides). We prefer to use Java for the parts where using Matlab is too painful, because it has great standard libraries, is easy to set up and is cross-platform. If we really need predictability and speed (i.e. no garbage collection or VMs loaded in the background) we use C++. For other tasks, especially signal processing, we use Matlab, because it is pretty much specifically made for it, is very high-level and has a nice environment with lots of relevant libraries. Occasionally when we need extra speed, we use Matlab’s ability to use C functions.

I think we are doing pretty well in using different languages for their strengths, although admittedly, sometimes these strengths are not so much in the languages themselves, but more in our familiarity with them. Integration is fairly easy, since these are really separate components that just interface through TCP (except when Matlab calls C, but this is pretty well-defined too). A problem is that most people here are researchers and not programmers, so most only know Matlab.
The number of people working on it varies, because usually people from our group just tend to help when they are asked, but are mostly also doing other stuff. I would say that only a couple of people are working on it at a time. Nobody received extra training, because everybody just does what they can. No extra people are hired, but sometimes other people are asked for help. Our methodology is definitely not waterfall, but I’m also hesitant to describe it as agile. The language selection process was basically just a couple of people conferring about which languages we knew and their strengths. I have to admit that we don’t really do testing beyond superficially checking if a function/class we just wrote seems to work and whether the application seems to be doing what it should. No fancy automated testing. Also, we are still in the process of building it, so there is not yet really any maintenance.

However, other than the fact that it might be hard to find people who know a language we used (in our department), I think for this project polyglot programming is working pretty well. However, it seems to be quite different from your typical business app and is very small-scale.


Graeme Rocher September 19, 2009 at 1:45 pm

Your concerns reflect exactly the reason why Groovy was created ie because other languages don’t integrate well enough with Java. For example I’ll answer your questions in turn as they relate to Groovy:

* how possible is to refactor code across multiple languages?

With in IntelliJ and Groovy this is dead simple. Rename a method on the Groovy side it renames all references on the Java side. Rename a method on the Java side and all Groovy references are renamed. You have full circular refactoring and since Groovy supports mixed dynamic and static typing you lose very little from a refactoring point of view.

* is it hard to navigate through layers of code written in multiple languages?

In IntelliJ you can CTRL+Click (or keyboard shortcut) navigate from Java to Groovy and Groovy to Java. No problems here.

* how hard is to switch from one paradigm to another?

The challenge with learning languages IMO is not with the language itself its learning the APIs. Groovy and Java share the same API, no problems here.

Only challenge some developers have is since Groovy is dynamic, you don’t have the same compile time assistance as in Java since method dispatch is resolved at runtime. So if you don’t have a unit testing culture this can lead to problems. But then you write tests don’t you? ;-)

* are any supporting materials necessary?

Yes all new languages require a learning curve, but Groovy is based off the Java 5 grammar and shares the same APIs so the learning curve is lower.

* how easy, fast and cost-effective to hire somebody?

Pretty much every competent Java developer is also a good Groovy developer. Some of the dynamisity takes getting used to, but overall the learning curve is relatively flat.

Take a look at the Grails codebase. It is rougly 50% Groovy and 50% Java and I personally never feel that it is problematic to maintain a mixed codebase like this because of the way Groovy and Java interoperate seamlessly.

All of the concerns you have raised relate to how the IDE supports a mixed code environment (joint compilation, cross language navigation, circular refactoring etc.). IntelliJ does really well at this and we’re (SpringSource) working on the Eclipse tooling which is starting to look really good.

I do however agree with you that if the languages you use don’t mix well (for example Java + JRuby/Jython/Rhino) then you have a problem and can end up with maintainability issues.


Alex Ruiz September 22, 2009 at 5:19 am

Thanks Graeme for your feedback! Like I mentioned in a comment to bwtaylor, I consider Groovy a special case. My exact words were:

“I think combining Java and Groovy is the simplest and safest path for polyglot programming, due to the proximity in syntax between two languages (by design.) On top of that, tool support for Groovy has improved a lot (in Netbeans and IntelliJ.)”

My only reservation is not to the language itself, but developers that write Java code in Groovy, without exploiting all the features that Groovy brings to the table. But that’s a different issue.



Tim September 20, 2009 at 5:22 pm

I think I 1/2 agree with this.

It does seem silly to consider what language to use whenever it’s time for a developer to address a problem. Even more silly if the list of options is too large.

It does seem reasonable for a team to say we are using languages X, Y, and Z. Then for each clearly define what they would be used for; X is for the data model, Y is for the GUI, and Z is for concurrency sensitive data processing. If all this is well defined in the development process then a number of the questions will go away.


Francesco Argese September 27, 2009 at 2:42 am

Hi guys, I have found this article very useful! I have read more about the argument polyglot programming on Wikipedia and in a promoting site of this approach (http://www.polyglotprogramming.com/).

I’m curious to know what do you think about Firefox Mozilla (core in C++ and Javascript for other higher level functionalities and plugins) or eMacs (core in C, higher level functionalities in LISP). They seems to be successfull experiments of polyglot programming.

Probably the success key is limiting the number of programming languages to two, one for the core (tipically C, C+ or Java) and the other to offer developers the opportunity to extend application or to write plugins in a more simple language that speeds up the development (tipically a scripting language or a domain specific language that offer a needed particular feature, see Lisp in eMacs ).

With this approach I think that one could think the process of developing a polyglot software divided into three teams: one that works only with core, one that works with integration beetween two languages (if necessary, see languages with great design similarity like Java and Groovy), and the other that work on the higher level functionalities.

Certainly is a cost (three separate teams) but the advantages could be enormous (see the expansion of Mozilla and eMacs).

Using a number of languages that exceeds two could be more difficult in the coordination. What do you think about my opinion?

Personally I have a little experience in C++ and Python polyglot programming and I have experienced some of the problems proposed by you (caused by C++ template complexity in particular). I think that using C as core language could be preferable because a great number of languges has a great compatibility with it considering that the core library of many languages (Python for example) are written in C and, for a C programmer, it is not very difficult to write a module callable from this languages.

Having a cross-language platform could be a great help to study polyglot programming. Do you know if exist something similar?


Andrew October 16, 2009 at 2:33 am

I agree with many of your points and recognise that within an organisation, you need to standardise on one or two languages for obvious reasons of maintainability.

However, I disagree with your overall conclusion. If I was forced to standardise on one language it would have to be C rather than Java for the simple reason there is nothing that could be done in Java that can’t be done in C whereas there are many things that C can do that Java can’t e.g. hardware interfaces, small efficient code, highly performant hand optimised code etc.

However I wouldn’t choose C to write a web application because I’d have too much framework code to write – I’d choose Ruby instead unless there was substantial enterprise integration involved in which case Java would be best choice.

For a Windows fat client, I’d probably choose C#.

For playing about and prototyping I’d choose Scheme.

I think, as a minimum, you need a high level DSL capable language like Scheme and a full featured low level langauge like C with seemless integration between them. Unfortunately Java is neither of these which is why Groovy, Clojure etc. have come along.


IPhone Development January 26, 2010 at 7:21 am

Interesting Post!


Phil June 9, 2010 at 10:00 am

I agree with you post. Here are two issues I have with Software Engineers that are okay with many languages but have not mastered one:

1. The learn-a-new-langauges-annually thing is so 1980′s. You could pick up a book like one by Peter Norton and know everything you need to know about computers then. Now, it takes years to get proficient (not good or great) at ASP.NET and C# (with its huge API). Plus, you got WPF, WF, EF 4 and many others. This is only in the .NET space. Now you have Ruby on Rail, Clojure etc- Rocky Lhotka full-time job is to keep current with just .NET and he cannot. Technology moves too fast and is too large to try everything and expect to know the quirks, bells and whistles to be competent.

2. C# has features from functional languages, dynamic languages OOP languages and more. This reduces the need to try to get a functional language feel from a pure functional language.

3. It takes dedication to become great at a tool/API, especially those with high learning curves (e.g. WPF.) Distracting yourself by trying to learn everything else can reduce you powess and mastery in a tool. If you are afraid of getting stuff knowing one thing that may be gone tommorrow, there will be tutorials. For example, Microsoft guided Software Engineers that moved from VB6 to VB.NET. You just will not be dead in the water.

Now, languages designers may need to learn a new language annually. Plus, it does not hurt if you learn a new languages annually just because you like programming. However, nowadays I do not feel that it is that urgent as it was in previous decades. Plus, polyglot-languages like C# lets you dive into non-OOP features. It is better to solve a programming the long way and quickly with a tool you are great at and can easily support THEN to build it with a more suitable tool you do not know well and will forces others to learn things way outside their area to support.


Leave a Comment

Previous post:

Next post: