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.