Skip to content
Print

How Do You Apply Polyglotism?

18
Aug
2008

For the past two years or so, there has been an increasing meme across the developer blogosphere encouraging the application of the polyglot methodology.  For those of you who have been living under a rock, the idea behind polyglot programming is that each section of a given project should use whatever language happens to be most applicable to the problem in question.  This makes for a great topic for arm-chair bloggers, leading to endless pontification and flame-wars on forum after forum, but it seems to be a bit more difficult to apply in the real world.

The fact is that very few companies are open to the idea of diversity in language selection.  Just look at Google, one of the most open-minded and developer-friendly companies around.  They employ some of the smartest people I know, programmers who have actually invented languages with wide-scale adoption.  However, this same company mandates the use of a very small set of languages including Python, Java, C++ and JavaScript.  If a company like Google can’t even bring itself to dabble in language diversity, what hope do we have for the Apples of the world?

A few months ago, I received an internal email from the startup company where I work.  This email was putting forth a new policy which would restrict all future developments to one of two languages: PHP or Java.  In fact, this policy went on to push for the eventual rewrite of all legacy projects which had been written in other languages including Objective-C, Ruby, Python and a fair number of shell scripts.  I was utterly flabbergasted (to say the least).  A few swift emails later, we were able to come to a more moderate position, but the prevailing attitude remains extremely focused on minimizing the choice of languages.

To my knowledge, this sort of policy is fairly common in the industry.  Companies (particularly those employing consultants) seem to prefer to keep the technologies employed to a minimum, focusing on the least-common denominator so as to reduce the requirements for incoming developer skill sets.  This is rather distressing to me, because I get a great deal of pleasure out of solving problems differently using alternative languages.  For example, I would have loved to build the clustering system at my company using the highly-scalable actor model with Scala, but the idea was shot down right out of the gate because it involved a non-mainstream language.  To be fair to my colleagues, the overall design involved was given more serious consideration, but it was always within the confines of Java, rather than the original actor-driven concept.

There is actually another aspect to this question: assuming you are allowed to use a variety of languages to "get the job done", how do you apply them?  Ola Bini has talked about the various layers of a system, but this is harder to see in practice than it would seem.  How do you define where to "draw the line" between using Java and Scala, or even the more dramatic differences between Java and JRuby or Groovy?  Of course, we can base our decision strictly on lines of code, but in that case, Scala would trump Java every time.  For that matter, Ruby would probably beat out the two of them, and I’m certainly not writing my next large-scale enterprise app exclusively in a dynamic language.

I realize this is somewhat of a cop-out post, just asking a question and never arriving at a satisfactory conclusion, but I would really like to know how other developers approach this issue.  What criteria do you weigh in making the decision to go with a particular language?  What sorts of languages work well for which tasks?  And above all, how do you convince your boss that this is the right way to go?  The floor is open, please enlighten me!  :-)

Comments

  1. Bite the bullet.
    But say no to java.

    Pick anything better and standardise on it. If you can move completely to Scala or Groovy, then do so! If minimising skillsets is important (even if only because management say so), then don’t fight it, but don’t give up in the face of it either.

    anon Monday, August 18, 2008 at 12:31 am
  2. The point is not so much to avoid Java as to try to introduce alternative languages *alongside* it. I actually like Java, it has some phenomenal tool support and it does what it was meant to do with a passing degree of excellence. I tend to think that standardizing exclusively on one or two specific languages is a bad thing and ultimately self-defeating, even if the languages in question are as nice as Scala or Groovy.

    I could be wrong though; is it better to rigidly standardize on something? If so, then definitely pick the more syntactically powerful language.

    Daniel Spiewak Monday, August 18, 2008 at 12:37 am
  3. You mention that you heard company soandso was doing interesting stuff in Scala, and maybe had some vacancies.

    The irony is that Scala has the potential to then do away with the polyglotism you’re calling for.

    Rob Monday, August 18, 2008 at 1:35 am
  4. If your *startup* has legacy projects, then maybe ur doing it wrong (not that I could boast).

    Adelle Hartley Monday, August 18, 2008 at 5:25 am
  5. There are real benefits in terms of deployment and configuration management of having the same language throughout and these often outweigh the language advantages. In many organisations I’ve consulted with I’ve seen development hovering around 100 days for development but testing being more like 400 and deployment being 50-100. Even if Ruby eliminated the development effort it wouldn’t eliminate the rest. But if by having all the same testing and deployment procedures then the cost for the company as a whole goes down. Language doesn’t in the grand scheme isn’t important, only developers care about it and the productivity differences.

    Saying that however an organisation that truly does service development (I hate how SOA has been distored by the big companies, lets just say its remote integration at a particular granularity) does allow multiple languages and products to exist in the same set of enterprise apps. Within any one service the cost likely outweighs the benefit, but different teams/services can use what they like. Alas the first point I make often removes any form of cost savings and hence it rarely happens except with a very compelling COTS product.

    Paul Keeble Monday, August 18, 2008 at 6:08 am
  6. at the first place, most companies are somewhat – busy – to let developers working for them to learn new language.

    on the other hand given that you have a team of experienced developers with the required languages, then the diversity of languages used is another task to manage.

    so, I think when languages like JRuby and Scala mature to the point that convince developers themselves on the first place that using diverse language of the same base, that could ease the task.

    Osama Monday, August 18, 2008 at 6:29 am
  7. To be fair to management (as people often forget to do), saying “I think we should use Scala instead of Java” could likely be a programmer’s way of saying “Look, I don’t want to learn/use Java, but I already know Scala!” Also, from management’s perspective it’s a lot easier to find someone who knows PHP and Java than someone who knows PHP, Java, Objective-C, Ruby, and Python.

    It sounds like you’re against the languages that you’re restricted to more than you’re against the restriction itself. There’s a lot more to this business than one developer’s personal preferences.

    Rob Monday, August 18, 2008 at 7:19 am
  8. Fact is, allowing a plethora of languages in development is a big liability for a company, because hiring people who know all those languages is expensive, and writing tools for each language is costly.

    Most programming languages expose the same or very similar sets of features. So, just like Google, you should minimize the set you allow to cover the majority of programming tasks:

    C++ – Low-level, fast.
    Java – High-level, medium.
    Python – Dynamic, slow.
    Javascript – Client-side web programming.

    James Monday, August 18, 2008 at 9:23 am
  9. I responded at length about this question on my blog. Not all of it is directed at your entry, but I took the time to explain that I thought limiting languages is not orthogonal to polyglotism, set the stage with quotes from various sources talking about it, offer an opinion as to what I thought each layer held (regarding Ola Bini’s idea that you referenced), and explain how I’m using Polyglot programming.

    Didn’t want to post the entire thing as a comment here (as I said, it’s lengthy) =). Anyway, if you’re interested after reading the summary, the full thing is at http://www.codeodor.com/index.cfm/2008/8/18/Dont-Fear-The-Poly-Headed-Polyglot-Monster/2475

    Thanks for bringing this up. There isn’t a lot of literature out there on this concept (at the moment, and as far as I know about), so hopefully this might end up producing some.

    Sammy Larbi Monday, August 18, 2008 at 10:47 am
  10. I’m finding a “Introduce then expand” approach might be feasible. I think you can’t just say, “hey, it’d be a good idea to use X as a langauge” without allowing people to code-review examples and work with it a bit beforehand.

    For example, I’m starting to write a lot of ‘non-production’ code in Scala. Our primary environment is this EJB-zombie-thing combined with several critical stored procedures. There are huge advantages of Scala:

    Compared with other dynamic JVM languages Scala was a lot easier to grok how I could create a “Bootstrap” EJB environment. (Well, with Guice.) It’s not that I couldn’t do this with something like JRuby, it just never dawned on me.

    With the maven Scala console, I no longer immediately pop open JBoss running under a debugger; it’s often faster for me to restart a console with the occasional print statement then JBoss. Note: this isn’t entirely “printf” debugging because I’m also compiling and experimenting with APIs in the console rather than just debugging.

    However, I don’t expect Scala to be used by anyone else for at least 6 months, maybe more. Why? Because they may not need to, plus, it can take people generally 3-6 months just to get used to it. “We shall see”, in other words. But if I am truly faster with the language (and I think I definitely am), that becomes a powerful argument. Plus, if people have a lot of examples within their domain, it becomes easier to learn.

    The two points I’m really trying to make:

    1. New languages should be significantly better to all current options
    2. You have to find an appropriate “in”

    In my experience, the larger the company, the harder the “in”.

    Tristan Juricek Monday, August 18, 2008 at 10:59 am
  11. To make a reliable program in a language, you need to be very fluent in that language, know its gotchas, etc. And learning that takes time. So unless you’re a genius, I don’t believe you can program very well in more than a few languages.

    IMHO, a program well-written in a language you master, is always better than a program poorly written in the best language for the task.

    Fabien Monday, August 18, 2008 at 11:03 am
  12. @Paul

    Valid points. Deployment is definately a reason to keep things limited to a single platform, but I’m not so sure about the “single language” under that platform. David Pollack wrote an article a few months ago about how Scala is “just another library”, and it’s really quite true. Scala deployment is *identical* to Java, just with one extra JAR dependency. I understand that Groovy has adopted the same design. JRuby is almost as simple (your build scripts probably require a bit of dancing to bring the .rb files along). I’ve never worked with Clojure, but I would imagine that it is at least as simple as JRuby deployment, maybe even easier.

    The point is that once the deployment infrastructure is in place for JVM apps, other languages which run on the JVM just fall out very naturally. A previous company I consulted for actually started experimenting with Scala shortly before my tenure was up. The decision to start implementing some of the core business logic in that language was made very easily and at a comparatively low-level in the management chain, due to the incredibly low impact of doing so. The project build was already using Maven, so it was just a matter of adding a few lines to the POM and no one (least of all the app server) was adversely affected.

    I guess I always expected deployment to be a non-issue when dealing exclusively with languages which run on the same platform and against the same infrastructure. Maybe there are some more complex scenarios where this is not the case, but I find it hard to imagine a Java build cycle that would be significantly altered by the introduction of a little Scala seasoning.

    @James

    It is true that companies are leery of upping the prerequisites for incoming developers, especially companies which are reliant on consultants. This actually was the primary argument (though unfortunately not the only one) against the adoption of Scala in my current gig. On the other hand, a correct implementation of the polyglot paradigm shouldn’t expect developers to know *every* language involved; that’s what modularity is designed to prevent. Going off of Ola’s “layers” idea, the developers working on the domain layer shouldn’t have to know how to maintain the stable layer since it is completely below their field of vision. As far as they are concerned, it is a completely black box API and language. Of course, if your company is trying to minimize the number of developers it needs to maintain the *whole* system, then yes it is an issue. But theoretically, it should be possible to keep everything nicely separated, especially if it is all on the same platform.

    @Sammy

    Very nice article. Definitely better to stick that in a proper post than to try to shoe-horn it into a comment. :-)

    @Tristan

    Interesting thoughts. There are certainly areas in my current development where I could employ such a technique. I have no doubt that it would still meet with resistance, but as long as it affects no one else, it might be alright. Definitely food for thought…

    Daniel Spiewak Monday, August 18, 2008 at 11:16 am
  13. Daniel:

    It’s generally about system configuration management. *Someone* has to install the new software components on all of the production servers (said to be in the hundreds of thousands for Google), has to watch for security alerts and such on all installed software components, and has to quickly install patches or updates on all of the production servers.

    Another problem of long-term note: what happens if the language developers stop working on it? I think that it’s glib to say “just keep using the last version”… sometimes the last version doesn’t work in new environments. Or worse, a major security vulnerability might be found in that last implementation.

    Another problem of long-term note: what happens when the servers are upgraded to a new version that is incompatible with existing applications? Scala, for example, has made a number of changes in the past that required some Scala programs to be modified. Martin has said that the pace of that should be a lot slower now. I doubt that the same can be said for, say, Groovy.

    And don’t underestimate what it takes for a new hire to learn a new language. It’s not just the language… it’s the idioms, coding styles, and (generally even moreso) the library and tools. Imagine a C++ developer jumping into a system built on Java, Eclipse, XML, Ant or (shudder) Maven, JUnit, EasyMock, Log4J and who knows what else from Apache commons, Tomcat and servlets, Spring, Hibernate, etc.

    Scala obviously isn’t as big a jump from Java as, say, Ruby is. Same JVM, mostly the same libraries, mostly the same tools. Very different idioms, though, especially if you listen to the folks who promote high order functions as the correct answer to just about everything.

    Consider this: many companies have felt compelled to issue “style rules” for their programmers’ creations. For Java, it’s generally stuff like capitalization, indentation, and the ever-popular issue of where to put the opening brace. If the coding style *within* a language is important enough to be specified by company dictate, clearly the choice of the language itself is even moreso. (That’s another fine can of worms opened.)

    Doug Monday, August 18, 2008 at 1:12 pm
  14. Well i am a programming novice with just 2 years experience i can tell you that regarding polyglotism:
    I work in a team where i am not the youngest but still the one with least programming experience.
    experience. We have very experienced COBOL programmers which eventually switched to java 4 years ago. For them from COBOL to java it was an enourmus amount of work. Sure they see that java is verbose in some cases and that alternatives liek groovy or scala do exist. But for a production System they would never use it ( BTW we run on java 1.4 :) )
    Summing up i would say using a significant range of languages is avoid because it simply means too much risk to “stakeholders”. And in fact it is a risk because you can’t tell them 100% for sure that using other languages you will get a better result. Maybe you get better results in certain components but then the interaction with other parts consumes this advantage. And so as i ( nor any other in my team) could’nt forsee the concrete consequences its simply avoided.
    Its just a lot of you would need to invest and that could turn into risk, and why add risk to the develeopement process?
    (yes you do eleminate chances but what peaks higher, again :)

    JavaNovice Monday, August 18, 2008 at 2:16 pm
  15. Daniel:

    I would agree that Scala, JRuby and groovy prove to be interesting. Indeed it now looks like .net’s approach to multiple languages is proving to be a decent long term strategy. This form of polygot programming brings little extra deployment cost so has a better chance of surviving. However they also don’t bring as big a paradigm shift as say Erlang and its difficult for the JVM/.net runtime environment to truly represent every possible approach out there. Parrot is another attempt to bring together languages and that too might bring the dynamic languages closer together.

    You still get a differences in the build infrastructure and process but the impact at least to production is reduced. It will be interesting to see what the adoption is in the next year of different but more advanced languages. I suspect the weirder languages (like erlang) are more compelling to use because of how different they are. More advanced features may be a programmer and maintenance benefit but if its not bringing a 10x performance improvement its unlikely to oust or get to sit aside with a current language imo.

    Paul Keeble Tuesday, August 19, 2008 at 6:09 am
  16. Polyglot development is great at first, possibly HORRIBLE later. Seriously, you guys are all dreamy about Scala and Groovy, but in 5-10 years, those languages may be out of favor, or may have upgraded and moved on in various ways and you’ll be hosed looking for support.

    I have worked with folks that alongside current development they have several legacy systems written in the hip/smart language/technology of their day. It is not pretty to have to deal with these systems over a long period of time. Eventually you end up spending a ton of money doing a top to bottom rewrite because the interoperability of systems gets too nasty. I’ve seen systems that we cannot recreate. The original devs are long gone. The hardware is out of date. The software is all not supported and won’t install. it’s a mess, but it’s a mess that pays our paychecks every two weeks. It’s the 1500 pound gorilla laying golden eggs that everybody’s afraid to stop, but absolutely has to be reigned in and reorganized.

    Some of the problem is that businesses (outside the IT dept) don’t like rewriting software constantly. They want to recoup a bit. This gets the code stale. This gets you into trouble. In a more perfect situation, we would have rewritten our components again and again over time as technologies improved, not in huge, expensive top to bottom rewrites.

    So maybe the take away is…. polyglot is a very neat idea. But beware. This is not for all organizations. Always be considering your maintenance strategy. Ask “Will this technology allow us to interop and refactor into the future?” before allowing it into the pool. “Does this tech have an exit strategy?”

    msp Tuesday, August 19, 2008 at 7:32 am
  17. @msp: those problems have little to do with polyglot programming — they have everything to do with poor execution. You get the same issue with COBOL systems, after all, where there’s no “poly” in sight. Basically, if you take shortcuts maintaining a system, you get what you deserve, regardless of the system’s implementation language.

    In choosing languages you have to be very aware of your context. If you’re in a startup and need to get something out the door as quickly as possible, then using a newer upcoming language could easily make the difference between succeeding or losing out big-time to a competitor. If you’re in a mainstream enterprise IT shop, though, then more of the concerns you (msp) raised come into play, but even there, choosing the right language can make a big difference over the lifetime of the system. One thing I like to say with respect to polyglot programming is “brevity matters.” It’s certainly not an original idea — Fred Brooks told us basically the same thing over 30 years ago. What it means is that generally, the smaller a system is, the easier and less expensive it is to maintain and extend. Brooks said that the cost of developing a program is on the order of N to the 1.5, where N is the number of instructions in the program. This means that if program B has 10x more lines of code than program A, it will generally be 32 times more expensive to develop and maintain. Therefore, choosing a language that lets you express the solution as succinctly as possible can be a huge win.

    @Daniel: to answer your original question, I think the old saying “ask forgiveness, not permission” (which is also my blog’s tagline, not surprisingly) comes into play. Sometimes you can try and try to convince management that using a certain language will be very beneficial, but regardless of what you tell them, they just won’t agree to it. So, don’t tell them — just do it. If you’re right, the system will be better for it, and other developers will have joined you in the meantime as they see the benefits, and ultimately management buys in because of reduced costs and enhanced functionality. If you’re wrong, well, you might have to pay the price, but if you take an agile approach, hopefully you can “fail fast” and still have time to recover. A better approach, obviously, would be somewhere in the middle: get management buy-in to build quick experiments and prototypes to help gauge whether a given language can help. In general, fostering a culture that supports experimentation and prototyping with iteration and agile approaches can help put you and your team in a very good place to be, regardless of which language(s) you use.

    Steve Vinoski Tuesday, August 19, 2008 at 2:42 pm
  18. It’s simple.

    Need exceeding good performance? Can you get amazing developers? Have to be closer to the OS? Go for C/C++.

    Need platform independence? Server-side or non-GUI application? Not really cared about native look and feel, etc? Go for Java.

    Need to build good native User Interfaces? Tight integration with the OS (like with the system tray or whatever)? Go for whatever is best on that particular OS. Like Objective-C with Cocoa API for OS/X instead of Java Swing. Oh, please, no Swing. I’ve seen too many sick Swing apps and they all, well, look not so good.

    And when choosing, go for the safest one. Like Java instead of some crazy Groovy. And occasionally, try out something new. So if a project has a server and client. Build the server in whatever language that seems like popular and better for the job and always right the client on the best one for the Operating System. I’m talking about thick clients here but the same can be said about browser based apps.

    But it’s safe to stick with the popular ones and not take Polyglotism too far. Like how Google’s doing.

    Srikanth Friday, August 22, 2008 at 10:12 am
  19. Customers don’t really care what programming language we developers use to deliver the working solution. Of course there could be situation where you have no option to select right language for right job. But what really matters to customers is return on investment and time to market. If I could deliver a new app with ruby/groovy(could be any language depending on problem domain) in less time compare to Java, I think the equation totally changes.
    I have noticed agile organizations are more quick in embracing right tools and technologies compare others.

    Nilanjan Sunday, September 7, 2008 at 10:10 am

Post a Comment

Comments are automatically formatted. Markup are either stripped or will cause large blocks of text to be eaten, depending on the phase of the moon. Code snippets should be wrapped in <pre>...</pre> tags. Indentation within pre tags will be preserved, and most instances of "<" and ">" will work without a problem.

Please note that first-time commenters are moderated, so don't panic if your comment doesn't appear immediately.

*
*