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.

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.

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?

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

Cheers,
-Alex

I’ll be watching your presentation shorty :)

Cheers!
-Alex

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

Cheers!
-Alex

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.

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