Hi Cédric,
I think that It should be obvious that there is a conflict of interests
here, and that agreeing to you suggestion looks to be worse for Groovy
than the very old saying by the original Groovy author about "never
having done Groovy if he had known a certain other language existed"
(all taken back later and no longer relevant - but still quoted in
discussions many years later).
Maybe I am missing something, but it seems to me that Jetbrains could
have put their weight behind Groovy, especially its static part, gaining
all the benefits with regards to tool support / Intellisense they now
claim for Kotlin (having worked with purely dynamic Groovy for years
using IntelliJ IDEA, I also have at least some doubts about the whole
"you cannot supply good Intellisense for Gradle DSL" mantra), also in
Gradle.
Instead they decided to develop their own independent language,
evidently very much inspired by Groovy, with imho some doubtful syntax &
design decisions where it deviates (and of course missing the dynamic
support and powerful annotations, as well as the big Groovy ecosystem).
Having Jetbrains behind it and evidently being heavily invested in it,
is not just another language on the block that joins the happy family of
Java alternatives. Jetbrains is pushing their language aggressively
(including but not restricted to on Wikipedia), and they have already
scored at least twice: One with the deal with Google Android
development, and second with Gradle adapting Kotlin as an alternative
base for its DSL.
The same as Jetbrains must want to get rid of supporting a complex
language like Groovy and replacing it with their own language if
possible for purely economical reasons (Note that some Groovy 2.5
features are still not supported in IntelliJ, months after release),
Gradle Inc. must want to only support a single DSL code base. Evidently
this is the Kotlin based one, otherwise why introduce it in the first
place ? The problem is that it seems uptake of the new DSL has been
slow, as people see no (or not enough) reason to switch from Groovy. So
of course there are no current plans to scrap Groovy support in Gradle,
since that would be suicide. You can try to convince me otherwisem but
it would be very surprising to me, if that would not change, should a
certain percentage of users shift.
I can't say how hard this would be on a technical level, and while it is
unlikely, it could potentially still be nice if Groovy and Kotlin would
join forces, with the static part of Groovy being merged with Kotlin,
just with nice groovy Java/Groovy syntax, and without the uselessly
restrictive things in Kotlin (that way people could actually choose what
language variety to use). Then this whole discussion would dissapear,
but since, as I said Jetbrains already decided against that option, and
instead invested several years into developing their own language from
scratch...*.
Just my 50 Cents (from "Get Groovy or Die Trying"),
mg
*Others here of course have much more insight than me into these
matters, including you (but see under conflict of interests).
On 20/03/2019 22:41, Cédric Champeau wrote:
Well I think I disagree with most of what you just said. And Gradle
Inc will not deprecate the groovy support anytime soon. I'm well
placed to know it's not even in discussion. The only thing that I see
could lead to such a decision would be that groovy doesn't run on
future versions of the JVM. Let's not take decisions on speculations,
but facts.
Le mer. 20 mars 2019 à 22:35, Sergio del Amo Caballero
<sergio.del...@softamo.com <mailto:sergio.del...@softamo.com>> a écrit :
I don’t know what do you imply that I am trying to hide.
I think:
- Gradle Groovy DSL helps Groovy adoption and thus survival.
same as Geb DSL on top of Selenium helps Groovy adoption and thus
survival.
I think if everyone moves to Kotlin DSL, Gradle Inc will lose
interest in maintaining Groovy Gradle DSL and eventually deprecate
the Groovy Gradle DSL and remove it and hurt Groovy adoption and
thus survival .
I think that Apache Groovy build transitions towards Kotlin DSL is
a signal towards prompting that move.
About maintaining the build itself:
- If the only person touching the build is going to be someone
with Kotlin and Groovy knowledge, then I would say better to have
the DSL in the language they are more productive with it.
- If persons, who touch the build, don’t know Kotlin, I think that
it is another barrier. I assume that someone with no Kotlin
Knowledge but using the Kotlin DSL and assisted by the IDE support
is going to do a worst job than someone with a lot of Groovy
knowledge using the Groovy Gradle DSL.
Sergio del Amo
On 20 Mar 2019, at 21:50, Cédric Champeau
<cedric.champ...@gmail.com <mailto:cedric.champ...@gmail.com>> wrote:
And do you honestly think that trying to hide that by not using
the Kotlin DSL would change anything?
Le mer. 20 mars 2019 à 21:45, Sergio Del Amo
<sergio.del...@softamo.com <mailto:sergio.del...@softamo.com>> a
écrit :
I do in fact see this as at least a minor threat. If Groovy
itself can't even manage to use the Gradle Groovy DSL, what
hope remains for the survival of the Groovy DSL?
Agree. I see a threat at least to Gradle Groovy DSL survival
and probably to Groovy in general. One may reason: If the
Groovy programming language build, which is manipulated by
the people with more Groovy knowledge in the planet, moved to
Kotlin DSL, why should anyone else keep using the Gradle
Groovy DSL.
Sergio
On 20 Mar 2019, at 16:00, Milles, Eric (TR Tech, Content &
Ops) <eric.mil...@thomsonreuters.com
<mailto:eric.mil...@thomsonreuters.com>> wrote:
I tried to get some info from Gradle on adding Eclipse DSLD
for Gradle and they scoffed at me. They said it was a
multi-person, multi-year effort so why even try. I was able
to get some very basic support without that much effort. It
could be moved forward and probably ported to IntelliJ as
well if there was some interest and support.
With regards to the change to the Groovy build script. I'm
not sure newcomers are diving into the build scripts and
making edits there. My intuition is that they are running
"./gradlew build" or whatever the command is. As long as
the scripts run successfully, I'd posit a newcomer is quite
happy.
I do in fact see this as at least a minor threat. If Groovy
itself can't even manage to use the Gradle Groovy DSL, what
hope remains for the survival of the Groovy DSL?
