RE: Consider statically typed/compiled as default for Groovy 3.0

[Winnebeck, Jason]

As for #2, note that Groovy code is compiled to bytecode as any other Java 
class. I use DCEVM + IntelliJ IDEA’s groovy gragent for hotswapping Groovy code 
and it works reasonably well. Not as good as Java, but Groovy works pretty 
well. It works well if you make sure not to add or remove closures when 
hotswapping. The vast majority of our code is static compiled. For reasons of 
performance, hotswapping, and debugging capability we use static as much as 
possible and try to reduce closures in use, even though they are the most 
powerful feature, we don’t use closures for example like with “each” method, 
instead we use plain for loops. Unfortunately, for some newer code now that we 
are on Java 8 where we used to have heavy closures code we instead use a Java 
helper class so we can use Streams API, which does not work well in Groovy, and 
also has the performance and hotswapping benefits.

If I was to consider forcing all Groovy code to static compilation at this 
time, I would seriously consider Kotlin instead of Groovy. Kotlin did not exist 
when we started our projects. That said, I have found no other JVM solution for 
dynamic consumption and production of webservices and schema-less structured 
data that compares to Groovy, and a hybrid Java+Kotlin+dynamic Groovy project 
is at best overcomplicated and I’m not even sure circular dependency is 
possible between the languages, therefore Groovy is still our language of 
choice for pairing with Java.

#4 is already implemented. In JVM the common language is bytecode and Groovy is 
a syntax sugar over bytecode, and bytecode already has a mapping of 
instructions to source code which is understood already by all JVM debugging 
tools. To do literally what you suggest would involve discarding the vast 
majority of the Groovy compiler and rewriting it to output Java code, which 
might not look much better than fernflower’s output but with improved variable 
names and possibly transfer of Javadoc. The other issue is that Groovy is a lot 
more than Java++ and requires a lot of helper code, particularly the MOP with 
dynamic groovy, that the Java output would not look like any kind of idiomatic 
Java that developers would want to work with.

Jason


From: Paco Zarate [mailto:conta...@nazcasistemas.com]
Sent: Monday, October 16, 2017 2:36 PM
To: users@groovy.apache.org
Cc: Paul King <pa...@asert.com.au>
Subject: Re: Consider statically typed/compiled as default for Groovy 3.0

I really like this topic.
1) Groovy syntax is incredible readable/maintainable. I take Groovy code from 
years ago and I am able to make changes easily. Thank you guys for this!

2) The dynamic portion of Groovy is interesting but it has some limits: when 
you are coding you need to recompile to see a change on a single line. Is it 
possible to have a the code recompiled on the fly? Is it possible in Groovy to 
step back during the debug? And finally, would be a way to be debugging Groovy 
code, hit a breakpoint, modify some already executed code on the fly, step back 
and rerun it? I guess all this is more tooling related than language related, 
but I would appreciate your opinions.

3) Have you seen the Smalltalk;s Pharo environment? they have visual tools to 
access and modify the Smalltalk app internals.  For example, see all the 
objects and modify then in the fly, include more code, save the state of the 
app (image) and reload it later. It is really interesting and I wonder if 
Groovy could use its dynamic nature that way.

4) For the static portion of Groovy: Have you think in the Typescript way of 
doing things? They are the "javascript++" but they have been doing it though 
transpiling to a very readable javascript. The option I see, would be to have 
Groovy generating Java code + maps for debugging. The use case would be: you 
work in a Java company, use Groovy to develop and then deliver to your company 
very readable Java code. I guess this may be doable with CompileStatic Groovy 
code and have a chance to apply too to generate Android Java code.


On Fri, Oct 13, 2017 at 7:14 AM, Cédric Champeau 
<cedric.champ...@gmail.com<mailto:cedric.champ...@gmail.com>> wrote:
Wise words, Paul. I would also very much prefer to see progress in the Java 9 
area rather than this, or even the parser. It's much more relevant to the 
future of Groovy IMHO. Because, as the ticket explains, there's already ways to 
enable this feature (even if a bit cumbersome). It's really of that importance, 
then a pull request, accepted through a VOTE, would certainly be the fastest 
way to get this.

2017-10-13 15:11 GMT+02:00 Paul King 
<pa...@asert.com.au<mailto:pa...@asert.com.au>>:
I think most committers are also keen on making progress in the directions you 
describe. Not along the lines of watering down Groovy's dynamic capabilities 
but certainly in terms of making Groovy's static nature as hassle free as 
possible to use. Having said that, we have limi

Re: Consider statically typed/compiled as default for Groovy 3.0

[Cédric Champeau]

Wise words, Paul. I would also very much prefer to see progress in the Java
9 area rather than this, or even the parser. It's much more relevant to the
future of Groovy IMHO. Because, as the ticket explains, there's already
ways to enable this feature (even if a bit cumbersome). It's really of that
importance, then a pull request, accepted through a VOTE, would certainly
be the fastest way to get this.

2017-10-13 15:11 GMT+02:00 Paul King :

> I think most committers are also keen on making progress in the directions
> you describe. Not along the lines of watering down Groovy's dynamic
> capabilities but certainly in terms of making Groovy's static nature as
> hassle free as possible to use. Having said that, we have limited
> resources, so we need to prioritise and do a limited numbers of things well
> rather than half do lots of things. Most of us have our own long list of
> technical issues that we think need working on (jdk9 support, new parser,
> bugs we know of in static type checking, many other features we'd like,
> etc.), so if you aren't seeing a lot of traction for this idea, it is
> possibly because we see a big list of things that would be needed to be
> sorted out to do this well and we are weighing up that list with our
> already long todo lists.
>
> Perhaps we wear our technical hats too much and should put on our
> marketing hats a bit more - who knows. All I can suggest to you is that
> Apache Groovy follows the Apache do-ocracy culture. If anyone picks off a
> small piece of the puzzle and advances it forward, it is likely to
> progress. But it's not guaranteed, so you are doing the right thing by
> discussing on the mailing lists. If you still don't get traction, start
> again with a smaller step.
>
> Cheers, Paul.
>
> On Fri, Oct 13, 2017 at 6:30 AM, MG  wrote:
>
>> blackdrag suggested to move this
>> https://issues.apache.org/jira/browse/GROOVY-8329
>> discussion from Jira to this list, so I am replying here:
>>
>> I agree with Endre Stølsvik: I think Groovy should strengthen its
>> language support for statically compiled use, and I agree it should move
>> towards making statically using it as hassle free as possible.
>>
>> I think Endre has already made some good points why this would be a good
>> idea, so I am just going to add that I am convinced that Groovy would not
>> be at 3% of the languages used after Java, but at > 30% (basically everyone
>> that could freely pick a language for commercial projects besides Java
>> would be using it) if it would fully be the Java++ it in fact is - in my
>> perception what kept it back was the fact that it "is slow" (true > 10
>> years back), that it is just "a script language" (never true afaik) - and
>> that it "is a dynamic language" (no longer true, but...). When I picked
>> Groovy for the project I work on, I did so despite it was dynamic, not
>> because of that (the static Groovy compiler that someone in Russia had
>> built at the time helped in the decision...).
>>
>> Being able to be dynamic in a language is a powerful feature, but one
>> that is needed only in special cases. Otherwise Groovy would already rule
>> the Java world ;-)
>>
>> Being able to have a very simple configscript that qualifies every class
>> with @CompileStatic is great (http://docs.groovy-lang.org/l
>> atest/html/documentation/#_static_compilation_by_default), but it is not
>> simple/easy enough: I agree there should be a "one click" option to turn
>> all of Groovy to using static compilation by default.
>>
>> Some ways to achieve this:
>> # Make a "static Groovy" download available (might just be based on
>> "including" the @CompileStatic configscript above)
>> # Compiler switch
>> # Choose during installation
>> # Express through the Groovy source file extension:
>> ## *.groovy ... use configured default
>> ## *.groovyd ... dynamic
>> ## *.groovys ... static
>> (alternatives: *.groovys, *.sgrv, *.grvs)
>>
>> The last option has the advantage, that everybody can use it easily
>> everwhere (Shell, IDE, ...), but the disadvantage that all the Groovy
>> examples out there use *.groovy, which would again might give the
>> impression to people that Groovy is "mostly a dynamic language". Maybe a
>> combination of people picking the default mode (dynamic/static) at
>> download/install time, with the extension approach would work best.
>> (That the Groovy compiler will try to compile any file with any extension
>> is OK. In that case I would suggest the fallback if the extension is not
>> known is dynamic compilation, for backward compatibility reasons.
>> Configuring extensions to mean dynamic or static compilation would of
>> course also be an option).
>> Or the Groovy compiler could throw if no --static or --dynamic compiler
>> switch was given ? That would force everyone to make a deliberate
>> decision... ;-)
>>
>> Just a quick brainstorming mail, to hopefully get the discussion going,
>> Markus
>>
>>
>>
>

Re: Consider statically typed/compiled as default for Groovy 3.0

[Paul King]

I think most committers are also keen on making progress in the directions
you describe. Not along the lines of watering down Groovy's dynamic
capabilities but certainly in terms of making Groovy's static nature as
hassle free as possible to use. Having said that, we have limited
resources, so we need to prioritise and do a limited numbers of things well
rather than half do lots of things. Most of us have our own long list of
technical issues that we think need working on (jdk9 support, new parser,
bugs we know of in static type checking, many other features we'd like,
etc.), so if you aren't seeing a lot of traction for this idea, it is
possibly because we see a big list of things that would be needed to be
sorted out to do this well and we are weighing up that list with our
already long todo lists.

Perhaps we wear our technical hats too much and should put on our marketing
hats a bit more - who knows. All I can suggest to you is that Apache Groovy
follows the Apache do-ocracy culture. If anyone picks off a small piece of
the puzzle and advances it forward, it is likely to progress. But it's not
guaranteed, so you are doing the right thing by discussing on the mailing
lists. If you still don't get traction, start again with a smaller step.

Cheers, Paul.

On Fri, Oct 13, 2017 at 6:30 AM, MG  wrote:

> blackdrag suggested to move this
> https://issues.apache.org/jira/browse/GROOVY-8329
> discussion from Jira to this list, so I am replying here:
>
> I agree with Endre Stølsvik: I think Groovy should strengthen its language
> support for statically compiled use, and I agree it should move towards
> making statically using it as hassle free as possible.
>
> I think Endre has already made some good points why this would be a good
> idea, so I am just going to add that I am convinced that Groovy would not
> be at 3% of the languages used after Java, but at > 30% (basically everyone
> that could freely pick a language for commercial projects besides Java
> would be using it) if it would fully be the Java++ it in fact is - in my
> perception what kept it back was the fact that it "is slow" (true > 10
> years back), that it is just "a script language" (never true afaik) - and
> that it "is a dynamic language" (no longer true, but...). When I picked
> Groovy for the project I work on, I did so despite it was dynamic, not
> because of that (the static Groovy compiler that someone in Russia had
> built at the time helped in the decision...).
>
> Being able to be dynamic in a language is a powerful feature, but one that
> is needed only in special cases. Otherwise Groovy would already rule the
> Java world ;-)
>
> Being able to have a very simple configscript that qualifies every class
> with @CompileStatic is great (http://docs.groovy-lang.org/l
> atest/html/documentation/#_static_compilation_by_default), but it is not
> simple/easy enough: I agree there should be a "one click" option to turn
> all of Groovy to using static compilation by default.
>
> Some ways to achieve this:
> # Make a "static Groovy" download available (might just be based on
> "including" the @CompileStatic configscript above)
> # Compiler switch
> # Choose during installation
> # Express through the Groovy source file extension:
> ## *.groovy ... use configured default
> ## *.groovyd ... dynamic
> ## *.groovys ... static
> (alternatives: *.groovys, *.sgrv, *.grvs)
>
> The last option has the advantage, that everybody can use it easily
> everwhere (Shell, IDE, ...), but the disadvantage that all the Groovy
> examples out there use *.groovy, which would again might give the
> impression to people that Groovy is "mostly a dynamic language". Maybe a
> combination of people picking the default mode (dynamic/static) at
> download/install time, with the extension approach would work best.
> (That the Groovy compiler will try to compile any file with any extension
> is OK. In that case I would suggest the fallback if the extension is not
> known is dynamic compilation, for backward compatibility reasons.
> Configuring extensions to mean dynamic or static compilation would of
> course also be an option).
> Or the Groovy compiler could throw if no --static or --dynamic compiler
> switch was given ? That would force everyone to make a deliberate
> decision... ;-)
>
> Just a quick brainstorming mail, to hopefully get the discussion going,
> Markus
>
>
>

Consider statically typed/compiled as default for Groovy 3.0 - PS

[MG]

PS: Just reread my post from yesterday, and wanted to add that I am of 
course happy that, like I said earlier, according to one study/metric it 
looks like Groovy is currently the #2 JVM language (with 3%) :-)
However, since it is "like Java, just better", I am convinced it could 
be much higher (and that to me is related to making static usage 
better/more convenient) - and one would not have to worry about Jetbrains...


(I am of course seeing this from the outside / a user's perspective - so 
if anyone has information that paints a different picture (see e.g. 
blackdrag's comment on the "DSL for Gradle" topic), please share / 
enlighten)

Consider statically typed/compiled as default for Groovy 3.0

[MG]

blackdrag suggested to move this
https://issues.apache.org/jira/browse/GROOVY-8329
discussion from Jira to this list, so I am replying here:

I agree with Endre Stølsvik: I think Groovy should strengthen its 
language support for statically compiled use, and I agree it should move 
towards making statically using it as hassle free as possible.


I think Endre has already made some good points why this would be a good 
idea, so I am just going to add that I am convinced that Groovy would 
not be at 3% of the languages used after Java, but at > 30% (basically 
everyone that could freely pick a language for commercial projects 
besides Java would be using it) if it would fully be the Java++ it in 
fact is - in my perception what kept it back was the fact that it "is 
slow" (true > 10 years back), that it is just "a script language" (never 
true afaik) - and that it "is a dynamic language" (no longer true, 
but...). When I picked Groovy for the project I work on, I did so 
despite it was dynamic, not because of that (the static Groovy compiler 
that someone in Russia had built at the time helped in the decision...).


Being able to be dynamic in a language is a powerful feature, but one 
that is needed only in special cases. Otherwise Groovy would already 
rule the Java world ;-)


Being able to have a very simple configscript that qualifies every class 
with @CompileStatic is great 
(http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default), 
but it is not simple/easy enough: I agree there should be a "one click" 
option to turn all of Groovy to using static compilation by default.


Some ways to achieve this:
# Make a "static Groovy" download available (might just be based on 
"including" the @CompileStatic configscript above)

# Compiler switch
# Choose during installation
# Express through the Groovy source file extension:
## *.groovy ... use configured default
## *.groovyd ... dynamic
## *.groovys ... static
(alternatives: *.groovys, *.sgrv, *.grvs)

The last option has the advantage, that everybody can use it easily 
everwhere (Shell, IDE, ...), but the disadvantage that all the Groovy 
examples out there use *.groovy, which would again might give the 
impression to people that Groovy is "mostly a dynamic language". Maybe a 
combination of people picking the default mode (dynamic/static) at 
download/install time, with the extension approach would work best.
(That the Groovy compiler will try to compile any file with any 
extension is OK. In that case I would suggest the fallback if the 
extension is not known is dynamic compilation, for backward 
compatibility reasons. Configuring extensions to mean dynamic or static 
compilation would of course also be an option).
Or the Groovy compiler could throw if no --static or --dynamic compiler 
switch was given ? That would force everyone to make a deliberate 
decision... ;-)


Just a quick brainstorming mail, to hopefully get the discussion going,
Markus