Once upon a time, they used to say every programmer has to learn a new programming language each year, just to stay in shape. When I mention this to Java programmers, they usually start laughing. What used to be true in the 70s, maybe even in the 80s and the early 90s, has become utterly impossible in 2016. Modern programming ecosystems like JavaEE have reached such a level of complexity that it has become challenging to master a single programming language, let alone a second.
Learning the core language is not the problem
Thing is, it doesn't suffice to learn the language. That's easy. Once you've learned an object oriented programming language, you'll quickly be fluent in any other object oriented language. Only shifting to another programming paradigm may give you a hard time. I, for one, have to admit I never managed to wrap my head around PROLOG. It's not difficult, but it's so different from what I'm usually doing. My rich experience which is so useful at other times prevents me from being a successful PROLOG programmer. But the vast majority of modern languages follow the procedural paradigm, spiced with object oriented programming or functional programming (and in same cases, both). So there's not to much a challenge from the language side per se.
Don't underestimate the ecosystem!
In 2016, learning a programming language is learning an entire programming ecosystem. When I started to experiment with Angular2 and TypeScript, I was sort of shocked to learn I couldn't work with the tool chain I already knew. More precisely, I was astonished I had to abandon every tool I was used to, the browser being the only exception. First I had to chose an editor with its own key bindings and its own user interface which didn't meet my expectations. Second, I had to install NPM. I didn't want to work with NPM, but it is needed to install other programs. So I had to make myself familiar with the concepts of NPM. After that, I had to install Grunt, Bower and a whole lot of other stuff I didn't really want to learn about. All I wanted to do is to use the TypeScript compiler. But virtually everybody in the TypeScript community uses tools like Grunt and Bower, so you have to install these tools even if you don't want to use them. Otherwise you have a hard time following the tutorials.
I'm often told no to make such a fuss of this. It takes only five minutes to install NPM, to what's the trouble?
The trouble is that there are so many things that require only five minutes. Selecting and installing a running TypeScript environment took me roughly two or three days. What seems to be simple to a professional TypeScript programmer is difficult for the rookies.
It's knowing the libraries and APIs what makes the difference
More important is, that this is only the start. The real trouble about learning a programming language is the libraries. That's why SAP consultants are paid such high hourly wages. It's not that ABAP is a difficult language. It's not. It's the fact that it takes years to learn how to use the libraries. That, and the fact that the SAP world sees to it that there are no resources freely available on the internet. As far as I know, there's no publicly available StackOverflow for ABAP programmers. It's a closed community, and you have to pay to get access to that guild.
The JavaEE community is much more open, but it has become difficult to master, too. Recently I've joined a project that takes full stack development seriously, including limited polyglot programming. This means the ideal team member is proficient at HTML, JavaScript, Bootstrap, AngularJS, WebServices, REST, JSF, JPA, CDI, aspect-oriented programming, writing services in an ESB and testing services with SOAP UI and the SAP IDE (if only the SE37), just to name a few. Given some time, it's possible to learn all that, but it's not not a walk in the park.
Back to topic: what about polyglot programming?
Where does this leave polyglot programming?
First of all, JaveEE programming is already polyglot programming. As to my experience, most Java developers nowadays are expected to be fluent with Java, HTML, CSS and JavaScript. Truth to tell, most of them aren't, but they know enough of these four languages to know how to ask StackOverflow.com for help. There's a reason why there are so many jokes on StackOverflow recently. It's an expression of frustration because of being more or less unable to program without internet access.
Talking of StackOverflow, if you're not a native speaker of English, there's another hurdle to jump over. I've seen enough issues written in broken English on our BootsFaces bug tracker to know that the dominance of English is just another challenge to many developers. Don't get me wrong: I'm happy those developers raise their voice despite the language barrier. I just want to point out there is such a challenge. Only one in three readers of BeyondJava.net lives in an English speaking country, so chances are the following sentence is true for you: even if you don't use any other language than Java, you already do polyglot programming: Java and English. By the way, that's one of the reasons why the BootsFaces team accept issues in many languages on our bugtracker: English, Spanish, Italian, German and French are fine to us. Don't expect us to answer in your language, but we're able to read issues posted in one of those language. We'd like to add more languages to the list, but I guess you've already got the gist of this article: there are only so many languages a guy can learn.
Adding an advanced language such as Groovy, Scala, Kotlin, TypeScript, Dart or Ceylon is to overwhelm your team. Chances are some of them will cope. But it's unlikely every team member will. I can clearly see this in the visitor statistics of BeyondJava.net. I've founded the web site to promote alternative JVM languages, but articles about these languages aren't read by many. The only exception being TypeScript. Articles about TypeScript and Angular2 tend to be almost as popular as articles about highly specialized JavaEE features.
I'm all for polyglot programming, but the sad truth is I can't evade the feeling that polyglot programming is demanding too much of my working mates. Mind you: What good is it if your current team is highly productive, but every new team member has so much to learn it takes them one or two years to become fully productive?
Assembly lines to the rescue!
Many teams try to solve the problem by Taylorism. In other words, introducing assembly lines. There's an assembly line responsible for the UI, a second assembly line for the backend, a third assembly line for writing the REST and SOAP services and so on. Even without introducing assembly lines, it's a matter of fact that almost every team has team members who concentrate on certain parts of the application, being weak at other parts of it. But making this division into an official strategy is a different story altogether. Before you know, your team members accept their role and deny to know anything about the other layers of their application. That may or may not work for you. The larger your company is, the more likely Taylorism is to succeed. But in any case it's dangerous. Knowledge is going to be fragmented. At the logical end, there's nobody left who understands the entire system. And that's a time bomb waiting to explode.
Again, that's nothing you can avoid in big projects. I daresay nobody understands the entire software of a modern airplane. Or of a car, for that matter. But still, I don't believe it's good to fragment knowledge about a project along technical layers. In my eyes, that's a high risk. If you have to fragment you project into different parts, into different teams that don't know much of each other, do it along business domains. Because in most cases you can't avoid learning about the business, anyways, which is adding just another layer of complexity. The alternative is to describe your specs in such a detailed manner that you can outsource your programming chores to, say, Bangalore. That's fine for the Indian job market, but it also means to jot down so many details - and to explain them over and over again - that you can just as well write the code itself. I know many European companies proudly announced to outsource their development to countries with lower wages, but I also know many of them silently reverted the process when they found out about the communications overhead.
Microservices to the rescue?
That train of thought is why I'm so attracted by the idea of microservices. More to the point, I'm attracted to the definition of microservices that includes the UI. Following this idea, a microservice deals with a small slice of the business domain. The resulting piece of software is small enough "to fit into my head". It is small enough to get new member to speed quickly. Or to get the repair team to speed quickly when they have to fix a bug or to add a feature to the microservice years later, when the original programmers already have left the company.
By the way, I don't say microservices are the silver bullet solving all kinds of problems. They're not. They replace one sort of problems by another. It depends on your company culture and on the business you're working on. If you're working in a company embracing communication, microservices are the right tool for you. Other companies prefer their employees to work instead of chatting. In such a culture, microservices may not flourish quite as well. Chances are business doesn't flourish in such an incommunicado culture, either, but that's another day's story.
Maintenance hell
There's another dirty secret spoiling the great idea of polyglot programming. Choosing the right tool for the job is a good idea when developing an application. But this also means you have to maintain the tool chain for many years. That's easy for mainstream languages like Java and JavaScript. It's more difficult for a heterogeneous zoo of languages like Java, Groovy, Scala and C++. It may turn out to be impossible if you add exotic languages or tools. Currently, there's no working Groovy Eclipse plugin for the current version of Eclipse 4.5. That's strange, because some nine months ago the Groovy eclipse plugin team announced that the snapshot of version 2.9.2 already supports Eclipse 4.5 and even Eclipse 4.6, but for some reason they haven't released this version yet. So even supporting a language like Groovy - which almost belongs to the mainstream, having risen to rank 18 of the March 2016 Tiobe index - may turn out to be a nightmare.
Custom DSLs are languages, too
Polyglot programming isn't limited to using more than one full-blown programming language. Another attractive option is to use a tool like XText to create a custom DSL. I'm very fond of XText. We're using a custom DSL in our BootsFaces project, and it's just great. It boosts productivity a lot by generating lots and lots of boring boilerplate code. But again, there's the trouble with long-term maintenance. XText in particular has suffered from a major change of the API. One the one hand, it's a good thing, because the current version is a lot better than the old version. But downside is that I know of at least one or two development teams stuck with the old version of XText. They've invested too much in it. Updating to the new version probably costs a lot of money (and time, not to mention the risk), so the teams are procrastinating. Thing is, there's no documentation of the old version of XText. The XText team have replaced their old documentation pages by the new manual. In other words: if you don't keep your software stack up-to-date, you may end up without helpful resources. As great as the internet is, it's much more volatile than books printed on paper. You'd rather save the documentation with an offline-reader as part of the release process.
It's not all about the development department!
Another aspect you should take into account is the operations department. They have to know how to run your programs. That's easy if your programs run on the JVM. But as soon as you start to mix different families of programming languages - say, the .NET framework, Ruby on Rails, server-side JavaScript, native C++ and the JVM - things start to get ugly. Maybe choosing the right tool for the right tasks cuts down costs in the development department, but it's raising costs in the operations department.
Wrapping it up
Where does this leave polyglot programming? As much as I hate to admit it, I've learned to become pessimistic. Or, to put it positively, I've learned that JavaEE programming is polyglot programming, even if you stick to the Java language. Mind you, how many items does JavaEE contain you can call a language in its own right? Just think of the of the JSF expression language (the spec consisting of 68 pages!), the Bean Validation API annotations and the Hibernate and JPA annotations. The latter class of annotations in particular has reached a level of complexity that it takes almost as long to learn and master them as it take to learn the base language (i.e. Java).
But still: I'm happy there are so many alternative languages around. In particular, I'm happy there are so many languages running on the JVM, because the JVM makes it a lot easier to use them of you're already working with a JVM language. The plethora of languages adds some helpful pressure to improve the Java language itself. It took a long time to add Lambda Expressions to the Java language. To bad the implementation team screwed up the collections API. They introduced defender methods to be able to use functional programming with every collection, just the way you're use to use lambdas in Groovy, but instead of adding the full Stream interface to every collection they added the stream() and get() methods. Now the API to use Lambda Expressions is to verbose that it renders Lambda Expressions mostly useless. I, for what it's worth, never use Lambdas in Java if there's a procedural alternative because of this ceremonial nonsense. But even so, it's a helpful addition to the language. Being able to pass methods as parameters to other methods is very useful, indeed. And the future has more in store for use: current plans include value types and local variable inference. So the value of alternative languages may be to be able to experiment with new features, and to port them back to the Java language when they've proved mature and useful.
Taking that in mind, BeyondJava.net won't stop reporting about new languages, even if nobody reads these articles :).
Dig deeper
Dangers of polyglot programming (in German language) (this is the article inspiring me to write this blog post)