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.

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.

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?”

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.

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

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…

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.

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”.