About Gradle, Kotlin and Inner Fear

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
123
Reply | Threaded
Open this post in threaded view
|

About Gradle, Kotlin and Inner Fear

ysb33r

As a follow-up to Dan Woods post regarding reactions of the ApacheGroovy community to the recent announcement of Kotlin support in Gradle, I had posted the following

  http://delivervalue.blogspot.co.uk/2016/05/about-gradle-kotlin-and-inner-fear.html

in the hope that it will elicit more conversation regarding the state of the Groovy nation.


-- 
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r
Reply | Threaded
Open this post in threaded view
|

Re: About Gradle, Kotlin and Inner Fear

Thibault Kruse
Cedric's comment linked at the bottom of that post is excellent in describing the issue. The gradle DSL has been designed in a way that is hard to support by IDEs, partly because groovy made that so easy. 

And the same might be true about other popular groovy frameworks. Having to support plugins for each IDE for each framework specific DSL is not viable.

If there were a lesson to be learned here for a vastly different groovy 3, it is hard to imagine that in practice those lessons could be applied.


On Monday, May 23, 2016, Schalk Cronjé <[hidden email]> wrote:

As a follow-up to Dan Woods post regarding reactions of the ApacheGroovy community to the recent announcement of Kotlin support in Gradle, I had posted the following

  http://delivervalue.blogspot.co.uk/2016/05/about-gradle-kotlin-and-inner-fear.html

in the hope that it will elicit more conversation regarding the state of the Groovy nation.


-- 
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r
Reply | Threaded
Open this post in threaded view
|

Re: About Gradle, Kotlin and Inner Fear

Jochen Theodorou
On 23.05.2016 10:59, Thibault Kruse wrote:

> Cedric's comment linked at the bottom of that post is excellent in
> describing the issue. The gradle DSL has been designed in a way that is
> hard to support by IDEs, partly because groovy made that so easy.
>
> And the same might be true about other popular groovy frameworks. Having
> to support plugins for each IDE for each framework specific DSL is not
> viable.
>
> If there were a lesson to be learned here for a vastly different groovy
> 3, it is hard to imagine that in practice those lessons could be applied.

The lesson would be to have static typed DSLs, and if you want to be
language implementation agnostic, you need the description in something
anyone can read. So the maximum that is allowed is annotations of some
kind - or a DSL to describe the DSL.

The later exists, is called GDSL, and even though IDE specific, it is
not very well supported by the same IDEs.

And what we have in first possibility might be on par with many other
DSL supporting languages, but not working out well enough for Gradle.
That is, if you want to keep the DSL as is.

I am wondering more about something like this:
http://mrhaki.blogspot.de/2013/05/gradle-goodness-extending-dsl.html

So if that basically means adding new DSL parts to any arbitrary (but
ExtensionAware) element in the build system. Then you need to define a
way to connect that in a static way for a static view to be able to do
static checks. I guess that would be extension functions then.. The
difference between their extension functions and our extension methods
is, that theirs is potentially more easy to use, since you do not need
to produce a descriptor. There was never really a need for that so far
in Groovy, but it certainly could be implemented. The static compiler
already understands extension methods, so it would be just a matter of a
different descriptor of some kind, plus making that available at compile
time.

I really would like to see a gradle DSL example in Kotlin that cannot
made static checked in Groovy. Because things like accessing dynamic
properties won´t work in Kotlin as well.

If they really wanted to there would be a way.

bye Jochen

Reply | Threaded
Open this post in threaded view
|

Re: About Gradle, Kotlin and Inner Fear

Cédric Champeau


I really would like to see a gradle DSL example in Kotlin that cannot made static checked in Groovy. Because things like accessing dynamic properties won´t work in Kotlin as well.

I made it very clear in my blog post: the Kotlin DSL is based on a new API that the static Groovy DSL could use too. That's not an issue. But Kotlin makes it significantly easier for IDEs because it is statically compiled, and therefore there's absolutely no need for an external DSL descriptor: all the constructs of the language, like extension methods or static builders are first class language features. The issue is, IDE support for Groovy is lacking (Groovy Eclipse is dead, IntelliJ needs to know specifics of static Gradle/Groovy scripts, ...)

We can discuss that during GR8Conf if you will. GDSL is definitely not an option: it's far from being enough, and too slow. And it wouldn't solve the issues with the current DSL. So a new DSL is designed, and Kotlin has been chosen because it's static first and has supported IDEs (both IDEA and Eclipse). I can make a static Groovy DSL, it wouldn't change this fact.

Reply | Threaded
Open this post in threaded view
|

Re: About Gradle, Kotlin and Inner Fear

Thibault Kruse
In reply to this post by Jochen Theodorou
It seems that Groovy already lost at Gradle, both Gradle and Pivotal
bet against Groovy.

It would be more interesting to investigate whether Gradle could
provide a programmatic API that allows easily using any JVM language
to define builds. Such that one may write a build.groovy instead of a
build.gradle, statically compiled, running against the gradle API.
Such that no custom editor besides a standard Groovy editor would be
needed in the first place. And there would be nothing stopping people
from writing build scripts in other languages like scala or clojure.
Maybe that's already possible, but my impression has been that the
current Gradle API is not that great to program against, nor is it
clear which parts are public API that can be relied upon and which
parts are internal and likely to change.

That approach would also be more future-proof.

On Mon, May 23, 2016 at 8:38 PM, Jochen Theodorou <[hidden email]> wrote:

> On 23.05.2016 10:59, Thibault Kruse wrote:
>>
>> Cedric's comment linked at the bottom of that post is excellent in
>> describing the issue. The gradle DSL has been designed in a way that is
>> hard to support by IDEs, partly because groovy made that so easy.
>>
>> And the same might be true about other popular groovy frameworks. Having
>> to support plugins for each IDE for each framework specific DSL is not
>> viable.
>>
>> If there were a lesson to be learned here for a vastly different groovy
>> 3, it is hard to imagine that in practice those lessons could be applied.
>
>
> The lesson would be to have static typed DSLs, and if you want to be
> language implementation agnostic, you need the description in something
> anyone can read. So the maximum that is allowed is annotations of some kind
> - or a DSL to describe the DSL.
>
> The later exists, is called GDSL, and even though IDE specific, it is not
> very well supported by the same IDEs.
>
> And what we have in first possibility might be on par with many other DSL
> supporting languages, but not working out well enough for Gradle. That is,
> if you want to keep the DSL as is.
>
> I am wondering more about something like this:
> http://mrhaki.blogspot.de/2013/05/gradle-goodness-extending-dsl.html
>
> So if that basically means adding new DSL parts to any arbitrary (but
> ExtensionAware) element in the build system. Then you need to define a way
> to connect that in a static way for a static view to be able to do static
> checks. I guess that would be extension functions then.. The difference
> between their extension functions and our extension methods is, that theirs
> is potentially more easy to use, since you do not need to produce a
> descriptor. There was never really a need for that so far in Groovy, but it
> certainly could be implemented. The static compiler already understands
> extension methods, so it would be just a matter of a different descriptor of
> some kind, plus making that available at compile time.
>
> I really would like to see a gradle DSL example in Kotlin that cannot made
> static checked in Groovy. Because things like accessing dynamic properties
> won´t work in Kotlin as well.
>
> If they really wanted to there would be a way.
>
> bye Jochen
>
Reply | Threaded
Open this post in threaded view
|

Re: About Gradle, Kotlin and Inner Fear

Andres Almiray
Or you know, use XML as a DSL and put the Maven vs. Gradle discussion to rest for good. (wink)

Joking aside, I'm aware that the tooling API has been improved a lot in past released; how much remains to be seen, and how much of that API relies on Groovy specific classes too.

Cheers,
Andres

-------------------------------------------
Java Champion; Groovy Enthusiast
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and those who don't.
To understand recursion, we must first understand recursion.

On Mon, May 23, 2016 at 1:59 PM, Thibault Kruse <[hidden email]> wrote:
It seems that Groovy already lost at Gradle, both Gradle and Pivotal
bet against Groovy.

It would be more interesting to investigate whether Gradle could
provide a programmatic API that allows easily using any JVM language
to define builds. Such that one may write a build.groovy instead of a
build.gradle, statically compiled, running against the gradle API.
Such that no custom editor besides a standard Groovy editor would be
needed in the first place. And there would be nothing stopping people
from writing build scripts in other languages like scala or clojure.
Maybe that's already possible, but my impression has been that the
current Gradle API is not that great to program against, nor is it
clear which parts are public API that can be relied upon and which
parts are internal and likely to change.

That approach would also be more future-proof.

On Mon, May 23, 2016 at 8:38 PM, Jochen Theodorou <[hidden email]> wrote:
> On 23.05.2016 10:59, Thibault Kruse wrote:
>>
>> Cedric's comment linked at the bottom of that post is excellent in
>> describing the issue. The gradle DSL has been designed in a way that is
>> hard to support by IDEs, partly because groovy made that so easy.
>>
>> And the same might be true about other popular groovy frameworks. Having
>> to support plugins for each IDE for each framework specific DSL is not
>> viable.
>>
>> If there were a lesson to be learned here for a vastly different groovy
>> 3, it is hard to imagine that in practice those lessons could be applied.
>
>
> The lesson would be to have static typed DSLs, and if you want to be
> language implementation agnostic, you need the description in something
> anyone can read. So the maximum that is allowed is annotations of some kind
> - or a DSL to describe the DSL.
>
> The later exists, is called GDSL, and even though IDE specific, it is not
> very well supported by the same IDEs.
>
> And what we have in first possibility might be on par with many other DSL
> supporting languages, but not working out well enough for Gradle. That is,
> if you want to keep the DSL as is.
>
> I am wondering more about something like this:
> http://mrhaki.blogspot.de/2013/05/gradle-goodness-extending-dsl.html
>
> So if that basically means adding new DSL parts to any arbitrary (but
> ExtensionAware) element in the build system. Then you need to define a way
> to connect that in a static way for a static view to be able to do static
> checks. I guess that would be extension functions then.. The difference
> between their extension functions and our extension methods is, that theirs
> is potentially more easy to use, since you do not need to produce a
> descriptor. There was never really a need for that so far in Groovy, but it
> certainly could be implemented. The static compiler already understands
> extension methods, so it would be just a matter of a different descriptor of
> some kind, plus making that available at compile time.
>
> I really would like to see a gradle DSL example in Kotlin that cannot made
> static checked in Groovy. Because things like accessing dynamic properties
> won´t work in Kotlin as well.
>
> If they really wanted to there would be a way.
>
> bye Jochen
>

Reply | Threaded
Open this post in threaded view
|

Re: About Gradle, Kotlin and Inner Fear

ysb33r
In reply to this post by Thibault Kruse
On 23/05/2016 12:59, Thibault Kruse wrote:
It would be more interesting to investigate whether Gradle could
provide a programmatic API that allows easily using any JVM language
to define builds. Such that one may write a build.groovy instead of a
build.gradle, statically compiled, running against the gradle API.
Such that no custom editor besides a standard Groovy editor would be
needed in the first place. And there would be nothing stopping people
from writing build scripts in other languages like scala or clojure.
Maybe that's already possible, but my impression has been that the
current Gradle API is not that great to program against, nor is it
clear which parts are public API that can be relied upon and which
parts are internal and likely to change.

*cringe*

This sounds too much like maven-polyglot to me.


-- 
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r
Reply | Threaded
Open this post in threaded view
|

Re: About Gradle, Kotlin and Inner Fear

Cédric Champeau
In reply to this post by Thibault Kruse
Thibault, this is exactly what Gradle is doing. The Kotlin support is the occasion to provide better APIs that are more friendly to static languages. In my post I have shown an example of the static Groovy version. The question is not whether we can do it or not. We can do it. The issue is IDE support. Have this scripts recognized by the IDE as such. Have a decent version of Groovy Eclipse. That is the challenge. The latter is important. I warned several times about the problem that nobody took over the development of Groovy Eclipse. If nobody does it, I bet that you can improve Groovy as much as you want, fix as many bugs as you want or add as many awesome features as you want, it's not going to be adopted anymore.

2016-05-23 13:59 GMT+02:00 Thibault Kruse <[hidden email]>:
It seems that Groovy already lost at Gradle, both Gradle and Pivotal
bet against Groovy.

It would be more interesting to investigate whether Gradle could
provide a programmatic API that allows easily using any JVM language
to define builds. Such that one may write a build.groovy instead of a
build.gradle, statically compiled, running against the gradle API.
Such that no custom editor besides a standard Groovy editor would be
needed in the first place. And there would be nothing stopping people
from writing build scripts in other languages like scala or clojure.
Maybe that's already possible, but my impression has been that the
current Gradle API is not that great to program against, nor is it
clear which parts are public API that can be relied upon and which
parts are internal and likely to change.

That approach would also be more future-proof.

On Mon, May 23, 2016 at 8:38 PM, Jochen Theodorou <[hidden email]> wrote:
> On 23.05.2016 10:59, Thibault Kruse wrote:
>>
>> Cedric's comment linked at the bottom of that post is excellent in
>> describing the issue. The gradle DSL has been designed in a way that is
>> hard to support by IDEs, partly because groovy made that so easy.
>>
>> And the same might be true about other popular groovy frameworks. Having
>> to support plugins for each IDE for each framework specific DSL is not
>> viable.
>>
>> If there were a lesson to be learned here for a vastly different groovy
>> 3, it is hard to imagine that in practice those lessons could be applied.
>
>
> The lesson would be to have static typed DSLs, and if you want to be
> language implementation agnostic, you need the description in something
> anyone can read. So the maximum that is allowed is annotations of some kind
> - or a DSL to describe the DSL.
>
> The later exists, is called GDSL, and even though IDE specific, it is not
> very well supported by the same IDEs.
>
> And what we have in first possibility might be on par with many other DSL
> supporting languages, but not working out well enough for Gradle. That is,
> if you want to keep the DSL as is.
>
> I am wondering more about something like this:
> http://mrhaki.blogspot.de/2013/05/gradle-goodness-extending-dsl.html
>
> So if that basically means adding new DSL parts to any arbitrary (but
> ExtensionAware) element in the build system. Then you need to define a way
> to connect that in a static way for a static view to be able to do static
> checks. I guess that would be extension functions then.. The difference
> between their extension functions and our extension methods is, that theirs
> is potentially more easy to use, since you do not need to produce a
> descriptor. There was never really a need for that so far in Groovy, but it
> certainly could be implemented. The static compiler already understands
> extension methods, so it would be just a matter of a different descriptor of
> some kind, plus making that available at compile time.
>
> I really would like to see a gradle DSL example in Kotlin that cannot made
> static checked in Groovy. Because things like accessing dynamic properties
> won´t work in Kotlin as well.
>
> If they really wanted to there would be a way.
>
> bye Jochen
>

Reply | Threaded
Open this post in threaded view
|

Re: About Gradle, Kotlin and Inner Fear

Thibault Kruse
> 2016-05-23 13:59 GMT+02:00 Thibault Kruse <[hidden email]>:
>>
>> It would be more interesting to investigate whether Gradle could
>> provide a programmatic API that allows easily using any JVM language
>> to define builds.
On Mon, May 23, 2016 at 9:05 PM, Cédric Champeau
<[hidden email]> wrote:
> Thibault, this is exactly what Gradle is doing. ...

In that case, there are two possibilitities. Either in all the
documentation, both Groovy and Kotlin will use the new, improved API.
Which probably implies lack of backwards compatibility, so all
build.gradle scripts have to be adapted when upgrading.

Or, Kotlin will use the new improved API in the documentation, whereas
the Groovy examples will keep the old API, meaning the old API is also
available from Kotlin (causing mess and confusion).

Could you clarify that?





On Mon, May 23, 2016 at 9:05 PM, Cédric Champeau
<[hidden email]> wrote:

> Thibault, this is exactly what Gradle is doing. The Kotlin support is the
> occasion to provide better APIs that are more friendly to static languages.
> In my post I have shown an example of the static Groovy version. The
> question is not whether we can do it or not. We can do it. The issue is IDE
> support. Have this scripts recognized by the IDE as such. Have a decent
> version of Groovy Eclipse. That is the challenge. The latter is important. I
> warned several times about the problem that nobody took over the development
> of Groovy Eclipse. If nobody does it, I bet that you can improve Groovy as
> much as you want, fix as many bugs as you want or add as many awesome
> features as you want, it's not going to be adopted anymore.
>
> 2016-05-23 13:59 GMT+02:00 Thibault Kruse <[hidden email]>:
>>
>> It seems that Groovy already lost at Gradle, both Gradle and Pivotal
>> bet against Groovy.
>>
>> It would be more interesting to investigate whether Gradle could
>> provide a programmatic API that allows easily using any JVM language
>> to define builds. Such that one may write a build.groovy instead of a
>> build.gradle, statically compiled, running against the gradle API.
>> Such that no custom editor besides a standard Groovy editor would be
>> needed in the first place. And there would be nothing stopping people
>> from writing build scripts in other languages like scala or clojure.
>> Maybe that's already possible, but my impression has been that the
>> current Gradle API is not that great to program against, nor is it
>> clear which parts are public API that can be relied upon and which
>> parts are internal and likely to change.
>>
>> That approach would also be more future-proof.
>>
>> On Mon, May 23, 2016 at 8:38 PM, Jochen Theodorou <[hidden email]>
>> wrote:
>> > On 23.05.2016 10:59, Thibault Kruse wrote:
>> >>
>> >> Cedric's comment linked at the bottom of that post is excellent in
>> >> describing the issue. The gradle DSL has been designed in a way that is
>> >> hard to support by IDEs, partly because groovy made that so easy.
>> >>
>> >> And the same might be true about other popular groovy frameworks.
>> >> Having
>> >> to support plugins for each IDE for each framework specific DSL is not
>> >> viable.
>> >>
>> >> If there were a lesson to be learned here for a vastly different groovy
>> >> 3, it is hard to imagine that in practice those lessons could be
>> >> applied.
>> >
>> >
>> > The lesson would be to have static typed DSLs, and if you want to be
>> > language implementation agnostic, you need the description in something
>> > anyone can read. So the maximum that is allowed is annotations of some
>> > kind
>> > - or a DSL to describe the DSL.
>> >
>> > The later exists, is called GDSL, and even though IDE specific, it is
>> > not
>> > very well supported by the same IDEs.
>> >
>> > And what we have in first possibility might be on par with many other
>> > DSL
>> > supporting languages, but not working out well enough for Gradle. That
>> > is,
>> > if you want to keep the DSL as is.
>> >
>> > I am wondering more about something like this:
>> > http://mrhaki.blogspot.de/2013/05/gradle-goodness-extending-dsl.html
>> >
>> > So if that basically means adding new DSL parts to any arbitrary (but
>> > ExtensionAware) element in the build system. Then you need to define a
>> > way
>> > to connect that in a static way for a static view to be able to do
>> > static
>> > checks. I guess that would be extension functions then.. The difference
>> > between their extension functions and our extension methods is, that
>> > theirs
>> > is potentially more easy to use, since you do not need to produce a
>> > descriptor. There was never really a need for that so far in Groovy, but
>> > it
>> > certainly could be implemented. The static compiler already understands
>> > extension methods, so it would be just a matter of a different
>> > descriptor of
>> > some kind, plus making that available at compile time.
>> >
>> > I really would like to see a gradle DSL example in Kotlin that cannot
>> > made
>> > static checked in Groovy. Because things like accessing dynamic
>> > properties
>> > won´t work in Kotlin as well.
>> >
>> > If they really wanted to there would be a way.
>> >
>> > bye Jochen
>> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: About Gradle, Kotlin and Inner Fear

Thibault Kruse
In reply to this post by ysb33r
On Mon, May 23, 2016 at 9:05 PM, Schalk Cronjé <[hidden email]> wrote:
> This sounds too much like maven-polyglot to me.

I think more along the lines of python setuptools. This is just a
python library, and it is called from python scripts like any other
python library. Why should Gradle not go that way, provide a library
for any JVM language to consume?

It is not quite like polyglot maven.

However, I also often think that it would also be useful if there was
a purely declarative DSL for programmatic builds that any buildsystem
could advertize to any IDE to describe the bits of the build relevant
to the IDE (e.g. all jars involved as dependencies with their
respective scopes, and maybe shell commands to invoke to process
certain tasks the IDE should not attempt to replicate).

Because that is the other problem of Gradle integration with any IDE;
that the IDE has to *execute* the build.gradle to find out e.g. the
dependency structure.
123