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