Wednesday, February 20, 2008

Language Shootout Followup

In my previous post on Our Language Shootout on choosing between Jython, JRuby, and Groovy, I made the following comment:
"This is especially important around the APIs, since it uses the Java APIs directly..."

Which received this question:
What caused you to come to that conclusion? I can certainly see it, but only if you continue to program Java but in Groovy instead. If that's the case, why take the performance hit just to write the same (type of) code? (You could just as easily "not learn" the other languages and program Java in their syntax.)

Rather than continuing down the comment trail, I wanted to respond to this specifically because it was a very important factor in our decision.

I firmly believe that for us to see the benefit of using a language like Groovy, we have to change the way we write code. It isn't just a matter of writing Java without types; and, if that is what it becomes, our experiment will fail. Regardless of whether we are using Python, Ruby, or Groovy, we better be writing idiomatic Python, Ruby, or Groovy code and not writing idiomatic Java code in said language.

Personally, this actually pushed me more towards Ruby, as I think it would force people to abandon their Java ways a little more forcefully. However, there are real business factors that need to be balanced. In my previous post, I talked about the current disruption versus the long-term gains. Organizationally, we have to be careful how much current disruption we take.

So that brings me back to my quote and the question raised. As I mentioned, every one of these language implementations can use the Java APIs. However, beyond the Java APIs, Jython and JRuby also include the Python and Ruby core libraries as well.

What that means is that, in Jython and JRuby, you now have multiple ways of skinning the same cat: one way is through the language core libraries and one is through the Java APIs. In general, that probably isn't a big deal, except the languages are optimized around their respective libraries. For me to write idiomatic Python, I really need to learn the Python core libraries. The same holds true for Ruby as well as Groovy.

But with Groovy, those core libraries are the Java APIs, which means that my developers don't have to learn a new API set in the process. That reduces the disruption in my current development process.

Now, that said, I also think that the Java APIs will reduce that top-line efficiency that could be gained. So this becomes a financial decision that includes things like amortization and the time-value of money. Given our current needs, I can't amortize this investment over much more than six months. Add to that the fact that money today is more valuable than that money in six months.

So that is why we felt that Groovy won that point for our company's needs at this particular time. If I were starting from scratch, I can guarantee that it would be the same decision as some of these Java-transition sticking points wouldn't have the pull and instead top-line efficiency would be paramount.

Not that Groovy is a bad place to be. :)


Al Power said...

Fascinating post - great to see the thought process you have gone through! Will be interesting to see how things go in the next 6 months.

Not meaning to be pedantic, but surely you meant "I cannot guarantee" rather than "I can guarantee" - although I'm sure most readers will see that!

Sammy Larbi said...

Thanks Travis, I now have a better understanding of what you meant in the previous post about the learning curve.

Where I was thinking of dynamic paradigms that how the power of brevity and clarity as what needed to be learned (the language side of things), you were focusing more on the objects and classes that help you get things done (the library side of things).

Travis Jensen said...

Al: Perhaps I did overstate the "I can guarantee", but I do feel the statement is stronger than "I cannot guarantee." It probably lands somewhere in "In all likelihood". Some of the major factors in choosing Groovy were because of our Java heritage. I really do believe that, in a world without that Java heritage, Groovy would not have come out on top.