Mailing-List: contact users-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.apache.org
MIME-Version: 1.0
Reply-To: paulk@asert.com.au
In-Reply-To: <741023cb-fa29-284b-be0e-b0f1825b6e81@arscreat.com>
References: <741023cb-fa29-284b-be0e-b0f1825b6e81@arscreat.com>
From: Paul King <paulk@asert.com.au>
Date: Fri, 13 Oct 2017 23:11:51 +1000
Message-ID: <CAMbkE7T=y8_rBZ9AmLf17g2KK+2Q42kiMzFSr6W3URY6kRzCgA@mail.gmail.com>
Subject: Re: Consider statically typed/compiled as default for Groovy 3.0
To: users@groovy.apache.org
Content-Type: multipart/alternative; boundary="001a113cda5075f71d055b6d665d"
archived-at: Fri, 13 Oct 2017 13:12:01 -0000

--001a113cda5075f71d055b6d665d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 <mgbiz@arscreat.com> 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=C3=B8lsvik: I think Groovy should strengthen its la=
nguage
> 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 everyo=
ne
> 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 tha=
t
> 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
>
>
>

--001a113cda5075f71d055b6d665d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think most committers are also keen on making progress i=
n the directions you describe. Not along the lines of watering down Groovy&=
#39;s dynamic capabilities but certainly in terms of making Groovy&#39;s st=
atic nature as hassle free as possible to use. Having said that, we have li=
mited resources, so we need to prioritise and do a limited numbers of thing=
s well rather than half do lots of things. Most of us have our own long lis=
t of technical issues that we think need working on (jdk9 support, new pars=
er, bugs we know of in static type checking, many other features we&#39;d l=
ike, etc.), so if you aren&#39;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 alrea=
dy long todo lists.<div><br></div><div>Perhaps we wear our technical hats t=
oo 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 cultu=
re. If anyone picks off a small piece of the puzzle and advances it forward=
, it is likely to progress. But it&#39;s not guaranteed, so you are doing t=
he right thing by discussing on the mailing lists. If you still don&#39;t g=
et traction, start again with a smaller step.<div><div><br></div><div>Cheer=
s, Paul.</div></div></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Fri, Oct 13, 2017 at 6:30 AM, MG <span dir=3D"ltr">&lt;=
<a href=3D"mailto:mgbiz@arscreat.com" target=3D"_blank">mgbiz@arscreat.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">blackdrag suggested=
 to move this<br>
<a href=3D"https://issues.apache.org/jira/browse/GROOVY-8329" rel=3D"norefe=
rrer" target=3D"_blank">https://issues.apache.org/jira<wbr>/browse/GROOVY-8=
329</a><br>
discussion from Jira to this list, so I am replying here:<br>
<br>
I agree with Endre St=C3=B8lsvik: I think Groovy should strengthen its lang=
uage support for statically compiled use, and I agree it should move toward=
s making statically using it as hassle free as possible.<br>
<br>
I think Endre has already made some good points why this would be a good id=
ea, 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 &gt; 30% (basically everyone=
 that could freely pick a language for commercial projects besides Java wou=
ld be using it) if it would fully be the Java++ it in fact is - in my perce=
ption what kept it back was the fact that it &quot;is slow&quot; (true &gt;=
 10 years back), that it is just &quot;a script language&quot; (never true =
afaik) - and that it &quot;is a dynamic language&quot; (no longer true, but=
...). When I picked Groovy for the project I work on, I did so despite it w=
as dynamic, not because of that (the static Groovy compiler that someone in=
 Russia had built at the time helped in the decision...).<br>
<br>
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 Ja=
va world ;-)<br>
<br>
Being able to have a very simple configscript that qualifies every class wi=
th @CompileStatic is great (<a href=3D"http://docs.groovy-lang.org/latest/h=
tml/documentation/#_static_compilation_by_default" rel=3D"noreferrer" targe=
t=3D"_blank">http://docs.groovy-lang.org/l<wbr>atest/html/documentation/#_s=
ta<wbr>tic_compilation_by_default</a>), but it is not simple/easy enough: I=
 agree there should be a &quot;one click&quot; option to turn all of Groovy=
 to using static compilation by default.<br>
<br>
Some ways to achieve this:<br>
# Make a &quot;static Groovy&quot; download available (might just be based =
on &quot;including&quot; the @CompileStatic configscript above)<br>
# Compiler switch<br>
# Choose during installation<br>
# Express through the Groovy source file extension:<br>
## *.groovy ... use configured default<br>
## *.groovyd ... dynamic<br>
## *.groovys ... static<br>
(alternatives: *.groovys, *.sgrv, *.grvs)<br>
<br>
The last option has the advantage, that everybody can use it easily everwhe=
re (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 &quot;mostly a dynamic language&quot;. Maybe a combination o=
f people picking the default mode (dynamic/static) at download/install time=
, with the extension approach would work best.<br>
(That the Groovy compiler will try to compile any file with any extension i=
s OK. In that case I would suggest the fallback if the extension is not kno=
wn is dynamic compilation, for backward compatibility reasons. Configuring =
extensions to mean dynamic or static compilation would of course also be an=
 option).<br>
Or the Groovy compiler could throw if no --static or --dynamic compiler swi=
tch was given ? That would force everyone to make a deliberate decision... =
;-)<br>
<br>
Just a quick brainstorming mail, to hopefully get the discussion going,<br>
Markus<br>
<br>
<br>
</blockquote></div><br></div>

--001a113cda5075f71d055b6d665d--