Re: Binary compatibility fixed + Kotlin DSL
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 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 mailto:cedric.champ...@gmail.com>> wrote: And do you honestly think that trying to hide that by not using the Kotlin DSL would change
Re: Binary compatibility fixed + Kotlin DSL
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> 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 > 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 > 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> 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? >> >>
Re: Binary compatibility fixed + Kotlin DSL
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 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 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) >>> 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?
Re: Binary compatibility fixed + Kotlin DSL
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 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> 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? > >
Re: Binary compatibility fixed + Kotlin DSL
> 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) > 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?
Re: Binary compatibility fixed + Kotlin DSL
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?
Re: Binary compatibility fixed + Kotlin DSL
I am probably -0 on the change at this time. I don't see this as a language threat issue but we are very keen to make the barrier to entry as low as possible for new contributors. Over time, I suspect more folks will have picked up some Kotlin exposure, so this wouldn't be as strong as a -1 from me. Cheers, Paul. On Wed, Mar 20, 2019 at 5:22 PM Cédric Champeau wrote: > Hi folks, > > Some of you have noticed that I have fixed the binary compatibility > reports on master. I also fixed checkstyle and CodeNarc, which were failing > to execute. I did not, however, fixed the many errors we see when running > those, nor the ones with spotbugs. It's a bit annoying because it makes the > "build" task fail, but we can live with that for some time. > > Some of you noticed, because this is the first time I introduce a Gradle > Kotlin DSL script for this. Let me explain why: first, it gives a better > user experience: completion in the IDE is working, and you can navigate to > sources. Second, its syntax is so close to the Groovy one that if I had > replaced .kts with .groovy, I bet hardly anyone would have noticed. > > To me it's a step towards a better build: we should'nt see this as a > threat to Groovy, and I'm not saying that it wouldn't have been possible to > achieve the same thing with Groovy, but this is the reality now: the Kotlin > DSL for Gradle gives a better UX than the Groovy one. I think it' going to > be particularly important for newcomers in the future. And as I am the main > maintainer of the build, it's also important to me, given the little amount > of time I can give to this project. My plan is to migrate the build to > Kotlin, slowly but surely, and as part of this effort, remove a lot of the > bad practices we're using, or internal APIs. Publishing for example is in a > terrible state. > > But coming back to this build script: take a look at it and tell me if > it's not as clear, or even more readable than the Groovy one (you can > compare with the old binarycompatibility.groovy file). Also, I strongly > believe that's an opportunity for us to learn from Kotlin and maybe borrow > some if its features > > So I'm asking you to vote on *keeping* this .kts file, and actually > migrating the build incrementally. If you see Kotlin as a threat, I'd > understand but would be disappointed. > > Thanks, >
Binary compatibility fixed + Kotlin DSL
Hi folks, Some of you have noticed that I have fixed the binary compatibility reports on master. I also fixed checkstyle and CodeNarc, which were failing to execute. I did not, however, fixed the many errors we see when running those, nor the ones with spotbugs. It's a bit annoying because it makes the "build" task fail, but we can live with that for some time. Some of you noticed, because this is the first time I introduce a Gradle Kotlin DSL script for this. Let me explain why: first, it gives a better user experience: completion in the IDE is working, and you can navigate to sources. Second, its syntax is so close to the Groovy one that if I had replaced .kts with .groovy, I bet hardly anyone would have noticed. To me it's a step towards a better build: we should'nt see this as a threat to Groovy, and I'm not saying that it wouldn't have been possible to achieve the same thing with Groovy, but this is the reality now: the Kotlin DSL for Gradle gives a better UX than the Groovy one. I think it' going to be particularly important for newcomers in the future. And as I am the main maintainer of the build, it's also important to me, given the little amount of time I can give to this project. My plan is to migrate the build to Kotlin, slowly but surely, and as part of this effort, remove a lot of the bad practices we're using, or internal APIs. Publishing for example is in a terrible state. But coming back to this build script: take a look at it and tell me if it's not as clear, or even more readable than the Groovy one (you can compare with the old binarycompatibility.groovy file). Also, I strongly believe that's an opportunity for us to learn from Kotlin and maybe borrow some if its features So I'm asking you to vote on *keeping* this .kts file, and actually migrating the build incrementally. If you see Kotlin as a threat, I'd understand but would be disappointed. Thanks,
