Does your workplace allow the use of multiple, interoperable programming languages?

Question

Since now there are several good languages that target the JVM and can interop with Java with varying degrees of painlessness, and likewise for the CLR (especially with the recent addition of F# as an "official" language for the platform), it seems to me like more places could take advantage of this but are afraid to.

In my own workplace, we can only write our components in C#. It's a good language, and I don't mind programming in it, but I'd really prefer to be able to use F# sometimes. I'm sure if we were in Java-land things would be similar, where I'd prefer Clojure or Scala. This is probably selfish of me, as I'm sure it's safer to stick with a lowest-common-denominator.

What are your thoughts on this issue? Should more people take advantage of the great interoperability on these platforms?

Answer 1

Take a typical web project. It usually mixes:

• a general-purpose language (e.g. Java or PHP or Python or...),
• SQL: even if you use ORM, you have to read SQL well,
• a templating language, usually not exactly dumb, e.g. XSLT or Smarty or Jinja,
• HTML + CSS in which you usually initially code your pages and then translate it to the templating language,
• Javascript, which can grow fairly complex in certain projects.

Here we omit build and deployment scripts which are usually 'too simple'.

Of course, usually people that deal with SQL are not the same people that deal with HTML. But usually all team members need at least an ability to read each other's code and understand it at least superficially.

Answer 2

For technical reasons, we mix Groovy and Java here. But I think that you should rather avoid such a mixture unless you have really good reasons. Maintenance becomes much harder when you have to know 5 different languages.

Answer 3

We have same restriction here, C# only; but we have the privilege to learn and develop hobby projects in any language we like, in free time.

From company perspective, it is the right decision. There are so many factors to consider like maintenance, knowledge transfer etc, and attrition level went up after recovering of recent financial crisis.

Answer 4

There is no problem in mixing languages. Any decent project is a way much more complicated than any programming language, so adding new languages won't affect a newcomers' learning curve. And if a particular language allows to reduce the complexity of a part of a project, it must be used. The common paranoia about using heterogeneous set of languages is absolutely unjustified and destructive.

Answer 5

We use a mix of C#, C++ and VB at work, in the same product.

This does lead to some interesting interop issues! It keeps my work interesting and challenging, which I think is a good thing, others may disagree?

This also means I gain experience in various languages and styles. Which can only be a good thing?

Answer 6

@Digger: What kind of interop issues? Is it the pure "don't CTS stuff that's not in the CLS" (which is already restricting you quite much), or are there more issues?

(Sorry, I wanted to comment, but have no permission to do that yet)

Answer 7

We mix Java and Groovy code in our projects. Groovy has been chosen over JRuby or Scala as it accepts normal Java syntax and has the usual benefits from dynamic languages. Usually we use Groovy for web-near stuff, sometimes using Grails to do the hard work for us that will take a lot of code to do in Java.

I would really like to see the use of more "modern" languages like Scala or Clojure, but that would take a lot of expensive and potentially unproductive retraining.

Answer 8

We use C# and VB.Net here. We don't normally mix languages on the same project, but are doing so on my present (fairly large) project.

The reason using both is that we decided to move from VB.Net to C# as our standard language, so we've still got a lot of VB.Net code to maintain. However, we do try to cut new code in C#.

Mixing languages does cause minor problems on the current project. During refactoring, for example, we occasionally need to move code between classes whose language is different. On the whole, however, these issues are rare and relatively easy to overcome. To a large extent, this is because (1) both languages are very similar, and (2) the project is fairly modular, and we tend to stick to a single language in each module. Occasionally, I've bulk-converted a module from C# to VB.Net, which has proven fairly easy in practice.

Personally, I'd like start using F# as well - but don't think that would be sanctioned any time soon, as there is little business justification.

Answer 9

We use both Java and C#, but in different departments, and never on the same projects.

Answer 10

Not good for business, But certainly interesting to personnel.