That depends on whether this honor is designed to promote Groovy and say thank you to people who are doing something for Groovy and the Groovy ecosystem right now, or if it is to honor people who have done so in the past, whatever they are doing right now.

Would you suggest we also honor Groovy inventor James Strachan, who wrote in 2009 in his Blog "I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.":

In comparison with Java Champions, Java is (or at least has been over a long period of time) a very slowly moving, stable platform. Most Java champions have built their professional careers around Java, which is also in no danger to be replaced by any other language within the JVM world, so they are extremely unlikely to do something detrimental to Java. In this regard Groovy is not similar to Java (see for instance your company's switch to Kotlin, which might or might not have been something you wanted, but which in any case happened).

Kotlin is not Scala, or Jython, or Ceylon. It is the language pushed by the company that makes the IDE that most Groovy development happens with, they can supply tool support for Kotlin that surpasses anything for any other language, and they will push any other language out, given the chance. It just makes economic sense - otherwise why invest in a new language in the first place ? For the same reason I would be surprised if Gradle will not, at some point, drop Groovy support, if Gradle users do not continue to predominantly use Groovy.

I am not dissing Alex Tkachman, btw: I know he did a lot for Groovy, and his groovypp compiler was the reason I made the leap of faith (see e.g. "I can honestly say if someone had shown me the Programming in Scala book..." above) and based a new project that was given to me on Groovy a few years back, thinking that I could always fall back to Groovy++'s static compilation support, should Groovy's performance not be enough (without having to resort to using Java instead). It was bad news when I learned that it seemed there had been some sort of conflict between the groovypp author and other Groovy devs, which did not like groovypp and instead wanted to go in a different, yet-to-be-implemented (!) direction of supplying optional static compilation using an annotation. Fortunately we now have @CompileStatic support, but for a time I was questioning my decision to go with Groovy in the first place, even if I had already come to like the language a lot by then.

I do not pretend to be an expert on the history of Groovy (or Gradle/Kotlin for that matter), but to me it looks like giving someone honors who is working on what looks like Groovy's biggest rival at the moment might, might not be the smartest move...

A long reply for sure, but it's a complicated topic,

On 14.02.2018 12:23, Cédric Champeau wrote:

    Or for something with a bit more pep "Groovy Vanguard Developer /
    Contributor 2018" or "Groovy Crack 2018".

    Contrary to Java Champions, I would suggest tying it to a specific

I like the idea of having it associated with a year, but it doesn't have to. Explanation below.

    That way people who no longer are Groovy contributors do not carry
    the title forever (the Russian guy who is now working on Kotlin
    comes to mind)

His name is Alex Tkachman, and while he's not involved in the language anymore, he's still one of the biggest contributors to Groovy. Most of the performance improvements in the "legacy" (non indy) dynamic runtime of Groovy were from him and still active. He was also source of inspiration for the static compiler (Groovy++). I think he deserves the title more than lots of us. And I think we shouldn't go into the "he's gone to competition" route. Languages evolve, Kotlin is a very nice language, that took inspiration from us as well as others, and we have lots of things to learn from it too.

Reply via email to