groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: Binary compatibility fixed + Kotlin DSL
Date Thu, 21 Mar 2019 06:44:46 GMT
There seems to be enough desire to keep the files as Groovy, so I'll revert
for the time being. We can look at this issue again a bit further down the
track and see if there is a greater level of comfort in switching.

Cheers, Paul.


On Thu, Mar 21, 2019 at 12:03 PM MG <mgbiz@arscreat.com> wrote:

> 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.delamo@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.champeau@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.delamo@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.milles@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?
>>>
>>>
>

Mime
View raw message