The comments on this blog were mostly geared toward Scala, the comments at dzone mostly made against polyglot programming, I'll do my best to address them here.
Let's start with Scala, a JVM language that "smoothly integrates features of object-oriented and functional languages" (don't take my word, the language site says it so), which definitely makes it very interesting to learn and play with. I haven't found something in particular yet that would prevent me from digging Scala, but it is the sentiment from the Scala community (if not the whole some of its more voiced advocates) that Scala is the successor of Java, and it is probably going to be the next big thing. If I were a monolingual developer I would surely agree with them right on the spot, but that is not the case. See the problem with Scala is that it is too advanced for its own good, it is not a blue collar language as Java is (was?). Blue collar language (as James Gosling recently exposed) means that developers with real world problems can solve said problems with the language, in other words put it to work right now. Java was conceived with a syntax much similar to C/C++, precisely to lure/convince developers. Another thing Java put into the table was a slight paradigm shift: the network is important so it is inherently represented in the language and its internals (JVM), this means not only simpler artifacts as Sockets/ServerSockets/Threads are available in the JSL, but class loading and security too.
Scala brings another paradigm shift from Java's point of view, namely smooth integration of object-oriented and functional features, so blue collar developers must be comfortable with both to really take advantage of the language itself. The hurdle in Scala's mass adoption is a generation gap. A couple of years after Java 1.0 was released Universities and Colleges around the world started to prefer Java over C/C++ as the language of choice to teach OOP practices, incidentally functional programming received less attention, which means that the new generation of developers do not have the proper education to get up to speed with functional programming, which means that if they were to pick Scala for their next project the code they would produce would be marginally better than Java (at best) thus reducing confidence on the language to solve real problems. It is easy to test this statement, people over 30 are most likely to have received functional programming at college and/or used functional programming languages at work (some still do). People from that group are the most vocal on Scala's imminent success. Besides being statically typed is not enough to be the next big thing (static vs dynamic is after all byzantine discussion).
A very thoughtful comment by Ian Griffiths on why Java will endure
When I started programming 30 years ago, we looked down on COBOL as a dead language. Curiously, even today, I keep on coming across packages of millions of lines of COBOL with teams of dedicated developers keeping them alive. So even after al language is recognized as obsolete, it will live on for tens of years until the applications written in it are no longer useful. For a popular language such as COBOL, FORTRAN, C, C++, VB, etc. probably 50 years or so.
In the case of Java, the doomssayers started their work very early. Before version 1.0, in fact. Java would never catch on: it was only good for writing Applets, an interpreted language could never be fast, support for CORBA was inadequate, the memory model was corrupt, Swing was too slow and low quality, etc. etc.
In fact, it would be interesting to go through the archives of Javalobby to chart the reasons Java was doomed over the last ten years. Not only have these predictions been proved wrong, but their authors have been demonstrated to have little or no grasp of the dynamics of IT economics and decision making.
Java covers an enormous field in IT from smart cards, embedded devices, mobile devices, desktop and enterprise computing. It has had, has and will always have, shortcomings somewhere or other. These shortcomings may only be a source of doom a) if they are really serious and there are no workarounds, b) if they will not be corrected in a reasonable timespan, c) if there is a clearly better alternative and d) if the better alternative offers guarantees of being around for twenty or thirty years.
Despite this constant bickering, no language available today offers sufficient advantages over Java to make a move worth while. Of course, for specialized jobs, there are interesting alternatives (scripting languages, etc.). There are also interesting experiments going on out there (f.e. Scala).
Today, if I have five million lines of Java code to manage, I can see no language that would justify using my budget to rewrite them rather than finance new functionality. I can not even find another language that would entice me to create a second pool of developers to write ne projects (that have to be interfaced with my main package). This does not mean that we don't use other languages, particularly scripting languages, for special tasks and prototyping or even proving algorithms.
I think the day when Java is recognized to be outdated and unsuitable for new projects is a long way off. And even then, it will still be around for thirty years or more longer.
Java can be found in many places, perhaps a "upstart" JVM language may dethrone it in one realm (say webapp development for instance) but it won't do the same in other realms, specially at the mobile camp, as the current implementation and memory footprint of some JVM languages make it prohibitive.
Polyglot programming is a paradigm shift too, so it naturally will have an opposing force. But change can't be prevented, only delayed. "Mutatis mutandis", "Panta rei", Hegel's dialectic demonstrate that change is in our nature, we can't remain still for so long, so if we require new tools to fulfill our daily work, we will find them, invent them, use them. Back to polyglot programming, some expressed concerns that if team members are not fully coordinated with their language knowledge then polyglot programming would play against them. I call rubbish, interchangeable team members is a fallacy, probably promoted by shameless consulting companies. We are individuals that can operate to form a larger entity (the team), summing up all our knowledge and experience, diversity increases synergy (but diversity must be focused on a team). Does your DBA know CSS? do your testers actually debug a stored procedure if your DBA quits? Does your designer digs webservice API design? Do your UI team can take over the job of the server team and vice versa? the most commons answer would be no. I too have faced that problem several times but it hardly holds off, not matter how many training sessions you submit your people, not everyone will be in the best disposition to learn the new tool, and later use it in the appropriate manner.
Another consequence of polyglot programming is that it make you learn how to approach a problem with several perspectives, in other words, drop your hammer if what you need is a screwdriver. Having a couple of polyglot programmers on your team would most of the time will help you in attacking the problem from different positions, allowing you to gather more data, eventually leading to more informed decisions. Polyglot programming is probably not for everyone, but it is my belief that it will play an important role in the years to come, why else is then Sun officially supporting 5 different languages (Java, JavaFX Script, JRuby, Jyhton, JavaScript (Rhino)) in the JVM today (more to come later? who knows).
</rant>
