Quantcast

static compilation for Groovy

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

static compilation for Groovy

Dierk König
Hiall,

given the latest discussions, I'd like to voice an opinion here
regarding the static compilation ideas.

Groovy dispatches by runtime type.

def foo(String x) { println 'String'}
def foo(Object x) { println 'Object'}

Object x = "Groovy"
foo x

prints "String" in Groovy (dispatch by runtime type)
but "Object" in Java (dispatch by static type).

Changing this would be a major language change.
Pretty much all relevant Groovy codebases that I know
of would be affected.

And what would we gain?
1) Performance
2) Static type checking

But both is already catered for by other means
up to an extend that makes sense for Groovy.

My considered opinion is that any static compilation
could only take place in extremely restricted areas where
1) the runtime-time type can be proven to always be the compile-time type
2) we do not want the MOP to be in charge of the dispatch.

IMHO this doesn't leave much area of applicability.

cheers
Dierk


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Cédric Champeau

Le 10/11/2011 19:51, Dierk König a écrit :
> Hiall,
hi!
> given the latest discussions, I'd like to voice an opinion here
> regarding the static compilation ideas.
good!

> Groovy dispatches by runtime type.
>
> def foo(String x) { println 'String'}
> def foo(Object x) { println 'Object'}
>
> Object x = "Groovy"
> foo x
>
> prints "String" in Groovy (dispatch by runtime type)
> but "Object" in Java (dispatch by static type).
Well, this discussion is closely tied to another problem, which is
supporting multimethods in static mode too. The idea here is to keep
semantics close to what Groovy does. It should already work in cases
where we can infer the type at compile time, like in your example (with
the idea that dispatch is based on inferred type). Having a complete
implementation of multimethods which supports the whole semantics of the
current groovy dispatch would somehow be more complicated (could mean
generate a method with multiple instanceof checks, but this would kill
performance), but certainly doable. We could process in various phases
until a possible release, with experiments on what we're able to do.
Furthermore, the support of invokedynamic could also help a lot in that
direction.

> Changing this would be a major language change.
> Pretty much all relevant Groovy codebases that I know
> of would be affected.
>
> And what would we gain?
> 1) Performance
> 2) Static type checking
>
> But both is already catered for by other means
> up to an extend that makes sense for Groovy.
>
> My considered opinion is that any static compilation
> could only take place in extremely restricted areas where
> 1) the runtime-time type can be proven to always be the compile-time type
> 2) we do not want the MOP to be in charge of the dispatch.
>
> IMHO this doesn't leave much area of applicability.
>
> cheers
> Dierk
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
>


--
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Jochen Theodorou
In reply to this post by Dierk König
Am 10.11.2011 19:51, schrieb Dierk König:
[...]
> My considered opinion is that any static compilation
> could only take place in extremely restricted areas where
> 1) the runtime-time type can be proven to always be the compile-time type
> 2) we do not want the MOP to be in charge of the dispatch.
>
> IMHO this doesn't leave much area of applicability.

I see here more a question of the user group. On Java7 for example it is
still open, how much you lose using invokedynamic compared to direct
method calls. Static types can help invokedynamic, and I wonder if the
future for static compilation of groovy lies not in invokedynamic, and
with that, actually not really doing static compilation.

The problems are what we give people that are not on Java7 the next 4
years and that current Groovy's MOP has some things preventing
invokedynamic to use full power.

The question is then actually... should we give people something for pre
Java7 or not? ... well, assuming invokedynamic (maybe with static type
checks) is about as fast as Java style compiled Groovy would be.

bye blackdrag


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Russel Winder
My fear here is that the direction of Groovy panders to the static type
adherents who despise all dynamic languages, and are very vocal in
damning Groovy because it is not Java, Scala, Kotlin, Ceylon.

I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
language to use as a complement to Java.  For performance critical
sections of code I use Java.  For dynamic components I use Groovy.  This
element of purity leads to clean and clear models of use.  This is an
easy sell in the training, take up and leveraging games.

Turning Groovy into a mish-mash language trying to kowtow to the wants
of a disparate and conflicting set of requirements seems like a recipe
for the demise of the language.

Groovy should not and should not even try to be a better Java.  It is a
symbiotic partner bringing different capabilities.  This is Groovy's
USP, and its sole reason for existing.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Dierk König
+1

Am 11.11.2011 um 10:59 schrieb Russel Winder:

> My fear here is that the direction of Groovy panders to the static type
> adherents who despise all dynamic languages, and are very vocal in
> damning Groovy because it is not Java, Scala, Kotlin, Ceylon.
>
> I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
> language to use as a complement to Java.  For performance critical
> sections of code I use Java.  For dynamic components I use Groovy.  This
> element of purity leads to clean and clear models of use.  This is an
> easy sell in the training, take up and leveraging games.
>
> Turning Groovy into a mish-mash language trying to kowtow to the wants
> of a disparate and conflicting set of requirements seems like a recipe
> for the demise of the language.
>
> Groovy should not and should not even try to be a better Java.  It is a
> symbiotic partner bringing different capabilities.  This is Groovy's
> USP, and its sole reason for existing.
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

tim yates-2
In reply to this post by Russel Winder
+1

On 11 November 2011 09:59, Russel Winder <[hidden email]> wrote:
My fear here is that the direction of Groovy panders to the static type
adherents who despise all dynamic languages, and are very vocal in
damning Groovy because it is not Java, Scala, Kotlin, Ceylon.

I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
language to use as a complement to Java.  For performance critical
sections of code I use Java.  For dynamic components I use Groovy.  This
element of purity leads to clean and clear models of use.  This is an
easy sell in the training, take up and leveraging games.

Turning Groovy into a mish-mash language trying to kowtow to the wants
of a disparate and conflicting set of requirements seems like a recipe
for the demise of the language.

Groovy should not and should not even try to be a better Java.  It is a
symbiotic partner bringing different capabilities.  This is Groovy's
USP, and its sole reason for existing.

--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Chanwit Kaewkasi
In reply to this post by Russel Winder
+1


On 11/11/2011, Russel Winder <[hidden email]> wrote:

> My fear here is that the direction of Groovy panders to the static type
> adherents who despise all dynamic languages, and are very vocal in
> damning Groovy because it is not Java, Scala, Kotlin, Ceylon.
>
> I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
> language to use as a complement to Java.  For performance critical
> sections of code I use Java.  For dynamic components I use Groovy.  This
> element of purity leads to clean and clear models of use.  This is an
> easy sell in the training, take up and leveraging games.
>
> Turning Groovy into a mish-mash language trying to kowtow to the wants
> of a disparate and conflicting set of requirements seems like a recipe
> for the demise of the language.
>
> Groovy should not and should not even try to be a better Java.  It is a
> symbiotic partner bringing different capabilities.  This is Groovy's
> USP, and its sole reason for existing.
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      t: +44 20 7585 2200   voip:
> sip:[hidden email]
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>

--
Sent from my mobile device

Chanwit Kaewkasi
code.google.com/p/zkgrails
twitter.com/chanwit

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

ld@ldaley.com
In reply to this post by Russel Winder

On 11/11/2011, at 9:59 AM, Russel Winder wrote:

> My fear here is that the direction of Groovy panders to the static type
> adherents who despise all dynamic languages, and are very vocal in
> damning Groovy because it is not Java, Scala, Kotlin, Ceylon.
>
> I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
> language to use as a complement to Java.  For performance critical
> sections of code I use Java.  For dynamic components I use Groovy.  This
> element of purity leads to clean and clear models of use.  This is an
> easy sell in the training, take up and leveraging games.
>
> Turning Groovy into a mish-mash language trying to kowtow to the wants
> of a disparate and conflicting set of requirements seems like a recipe
> for the demise of the language.
>
> Groovy should not and should not even try to be a better Java.  It is a
> symbiotic partner bringing different capabilities.  This is Groovy's
> USP, and its sole reason for existing.

Well said, I agree completely.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Václav Pech
In reply to this post by Russel Winder
Close to what I feel (and fear).

On Fri, Nov 11, 2011 at 10:59 AM, Russel Winder <[hidden email]> wrote:
My fear here is that the direction of Groovy panders to the static type
adherents who despise all dynamic languages, and are very vocal in
damning Groovy because it is not Java, Scala, Kotlin, Ceylon.

I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
language to use as a complement to Java.  For performance critical
sections of code I use Java.  For dynamic components I use Groovy.  This
element of purity leads to clean and clear models of use.  This is an
easy sell in the training, take up and leveraging games.

Turning Groovy into a mish-mash language trying to kowtow to the wants
of a disparate and conflicting set of requirements seems like a recipe
for the demise of the language.

Groovy should not and should not even try to be a better Java.  It is a
symbiotic partner bringing different capabilities.  This is Groovy's
USP, and its sole reason for existing.

--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Graeme Rocher-4
In reply to this post by ld@ldaley.com
On Fri, Nov 11, 2011 at 11:52 AM, [hidden email] <[hidden email]> wrote:

>
> On 11/11/2011, at 9:59 AM, Russel Winder wrote:
>
>> My fear here is that the direction of Groovy panders to the static type
>> adherents who despise all dynamic languages, and are very vocal in
>> damning Groovy because it is not Java, Scala, Kotlin, Ceylon.
>>
>> I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
>> language to use as a complement to Java.  For performance critical
>> sections of code I use Java.  For dynamic components I use Groovy.  This
>> element of purity leads to clean and clear models of use.  This is an
>> easy sell in the training, take up and leveraging games.

I agree too, hence I wouldn't want to position this feature as
competition for Scala, Kotlin etc. Groovy should remain dynamic
focused.

Having said that I would like to be able to selectively choose a
method/class or even a method call in Groovy that should bypass MOP
calls.

I don't want to have to drop down to Java since my personal
productivity dips significantly.

I suggested at one point as a minimum (if we don't add full static
compilation) it would at least be nice to have a dot operator
equivalent that dispatches statically. Such as

foo->callMe()

We should experiment with different solutions in this area and keep
innovating. Maybe full static compilation is not required (although
static type checking I think it definitely a nice to have)

Cheers

>>
>> Turning Groovy into a mish-mash language trying to kowtow to the wants
>> of a disparate and conflicting set of requirements seems like a recipe
>> for the demise of the language.
>>
>> Groovy should not and should not even try to be a better Java.  It is a
>> symbiotic partner bringing different capabilities.  This is Groovy's
>> USP, and its sole reason for existing.
>
> Well said, I agree completely.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Jochen Theodorou
Am 11.11.2011 13:57, schrieb Graeme Rocher:
[...]
> foo->callMe()
>
> We should experiment with different solutions in this area and keep
> innovating. Maybe full static compilation is not required (although
> static type checking I think it definitely a nice to have)

one thing I wonder about in this one is operators. I mean from my
experiments with for example the fibonacci function I found, that if you
have direct method calls, you get improved performance, but only about
20%. The operators are dominating so much - especially the compare -
that it is a question if that is really worth it. What I want to say is,
that if you want maximum performance with this one, then you need to
express all operators as method calls. And even then the compiler has to
find the method at compile time.

It very much depends on your case.

I use another use for it though... writing DGM in Groovy... there we
need sometimtes to call the original method directly

bye blackdrag

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Cédric Champeau
In reply to this post by Russel Winder
Hi Russel!
Le 11/11/2011 10:59, Russel Winder a écrit :
>
> My fear here is that the direction of Groovy panders to the static type
> adherents who despise all dynamic languages, and are very vocal in
> damning Groovy because it is not Java, Scala, Kotlin, Ceylon.

Well, looking at the answers to your email, it looks like it's more
the dynamic folks who are more vocal on this list :)
>
>
> I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
> language to use as a complement to Java.  For performance critical
> sections of code I use Java.  For dynamic components I use Groovy.  This
> element of purity leads to clean and clear models of use.  This is an
> easy sell in the training, take up and leveraging games.

I understand (and respect) your opinion, but I think it is biaised.
Groovy is not *only* a dynamic language. It is:
   a. an extension to Java (not meant to replace it, but work nicely with it)
   b. a dynamic language
   c. a scripting language
   d. an OOP language with functional features

After having worked with Groovy for a few years, with different people
with different opinions regarding static checking, dynamic languages
and so on, I can tell that conciseness and syntax matters. Many people
already use Groovy "as a Java with a better syntax". This is not
future, this is a fact. Those people do not use (or in very rare
occasions) the dynamic features of Groovy. They like the language
because it removes most of the verbosity from Java, but keeping a
syntax which is very close to Java. In my past company, I reviewed
code written in Groovy not by me, but by either Java specialists or
beginners, and figured out that almost none used dynamic features. In
fact there were two common usages:
   - scripting
   - DSLs

In the first case, most of errors were due to typos and leak of static
type checking. In the second case, I can speak properly because I had
written a text extraction engine which used Groovy as a DSL support
language. First, I started with runtime metaprogramming, then quickly
moved to compile time metaprogramming (AST transformations). The more
I used Groovy, the more I replaced runtime metaprogramming with AST
xforms. The main reason *was* performance, but also static checking.
So if you consider that static type checking is a must have feature
(as I do think, and comments to the announcement like "this is
awesome, exactly what I was waiting for" or "if static compilation
comes to Groovy, I'd definitely use it in place of Scala" make me
think we go in the right direction), then it is to me going halfway
not to statically compile and propose optimized bytecode. If code is
statically checked, then you definitely loose, for the parts that are
statically checked, the ability to go dynamic... If you can't use
dynamics, then static compilation makes sense. This is what you fear,
but this is exactly one feature I missed for years in Groovy: a less
verbose Java with compile time metaprogramming and comparable runtime
performance. This absolutely doesn't mean that this should be the
*default* behaviour, and this is why we chose to implement
@TypeChecked as an annotation, which could be used by other AST xforms
requiring type inference, and eventually by a static compiler.
Deciding whether we should also propose a static compiler or not
requires at least, IMHO, an experiment. If we follow the target
release plan for 2.0, then static compilation experiments should start
quickly, but this is another debate.

One of your key points was that you can use Java when you need
performance, and Groovy when you need dynamics. This is true, but this
is missing the fact that you may want to have everything written in
Groovy without a single line of dynamic code. In practice, for having
done this kind of development for 5 years, I can tell that mixing Java
and Groovy code is often not that easy (mixed mode, stub generation
failures, maven plugin, ...), and there are places where writing a
class in Java for performance, and the other one in Groovy for
expressiveness is a nonsense. If you could use one language, why
wouldn't you ? It's even worse when you are obliged to split a class
-or a method- into multiple ones for performance reasons. Think of
closures, for example... You fear that Groovy becomes a "failed Java
8", but I fear more that Java 8 doesn't go in Groovy's direction. We
also used, though it's true with less experience, Grails as a web
framework. And while productivity increased sensitively, the
developers kept complaining about the lack of static checking.

I really think Groovy is awesome because it offers two key aspects :
   * a Java-like syntax which makes the learning curve almost null (to
be compared with other JVM languages)
   * the ability to use dynamics

Not every people like dynamic languages. I do, you do, and lots of
people on this ML do. However, in terms of JVM scripting languages,
there are not so many alternatives. I honestly think Groovy has
something to propose here with static type checking and, for
performance reasons, static compilation. What I fear is that if we do
not go in that direction, the true vocal people, those from Scala,
Dart, ... will turn Groovy into a niche language.
>
> Turning Groovy into a mish-mash language trying to kowtow to the wants
> of a disparate and conflicting set of requirements seems like a recipe
> for the demise of the language.
>
> Groovy should not and should not even try to be a better Java.  It is a
> symbiotic partner bringing different capabilities.  This is Groovy's
> USP, and its sole reason for existing.
>

--
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Johnny Jian-2
Hi all,

I want to say something about my thoughts on static type checking and static compilation.

I think static type checking is a great idea. I view it as an opposite to the @SuppressWarnings annotation in Java which turns off the warnings from the compiler, while @TypeChecked turns on the warnings/errors from the compiler. And it is the savior for typos.

On the other hand, static compilation sounds like a bad idea to me, because it changes the semantics of groovy (groovy++ is an example). IMO, groovy should be always dynamic.

I think there are only two reasons for static compilation: performance and avoiding metaclass (as we do in gmock). However, can static groovy faster than pure java? And can it be more explicit to avoid metaclass than writing in java?

All the users need is just an easy way to embed java code into groovy code: a "java { ... }" block or a @Java AST transformation, instead of a separated java class. I cannot recall any desire for static groovy on the mailing list, but for the @Java AST transformation. If you ask a java programmer who is interested in groovy, which will he choose between static groovy and embedding java code, I bet the later one.

I already have an implementation approach in my mind, but I am not familiar with compilers, so I don't know where to start.

Let's say that we have a groovy class with @Java:

class Foo {
  @Java
  public void bar() { ... }
}

will be transformed into:

class Foo {
  private Foo$Java $java = new Foo$Java(this)
  public void bar() { $java.bar() }
}
// and a java class
class Foo$Java {
  ...
  public void bar() { ... }
}

then a joint compilation is all we need.

I remember that Jochen mentioned that there will be an syntax conflict between groovy and java. But how can groovy++ do so while it introduces some new grammars? If indeed we cannot handle the conflict, it is actually not a big deal as groovy supports almost all syntax of java, so just, for example, disallow java style array initialization.

Johnny
2011-11-12

On Fri, Nov 11, 2011 at 9:27 PM, Cédric Champeau <[hidden email]> wrote:
Hi Russel!
Le 11/11/2011 10:59, Russel Winder a écrit :
>
> My fear here is that the direction of Groovy panders to the static type
> adherents who despise all dynamic languages, and are very vocal in
> damning Groovy because it is not Java, Scala, Kotlin, Ceylon.

Well, looking at the answers to your email, it looks like it's more
the dynamic folks who are more vocal on this list :)
>
>
> I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
> language to use as a complement to Java.  For performance critical
> sections of code I use Java.  For dynamic components I use Groovy.  This
> element of purity leads to clean and clear models of use.  This is an
> easy sell in the training, take up and leveraging games.

I understand (and respect) your opinion, but I think it is biaised.
Groovy is not *only* a dynamic language. It is:
   a. an extension to Java (not meant to replace it, but work nicely with it)
   b. a dynamic language
   c. a scripting language
   d. an OOP language with functional features

After having worked with Groovy for a few years, with different people
with different opinions regarding static checking, dynamic languages
and so on, I can tell that conciseness and syntax matters. Many people
already use Groovy "as a Java with a better syntax". This is not
future, this is a fact. Those people do not use (or in very rare
occasions) the dynamic features of Groovy. They like the language
because it removes most of the verbosity from Java, but keeping a
syntax which is very close to Java. In my past company, I reviewed
code written in Groovy not by me, but by either Java specialists or
beginners, and figured out that almost none used dynamic features. In
fact there were two common usages:
   - scripting
   - DSLs

In the first case, most of errors were due to typos and leak of static
type checking. In the second case, I can speak properly because I had
written a text extraction engine which used Groovy as a DSL support
language. First, I started with runtime metaprogramming, then quickly
moved to compile time metaprogramming (AST transformations). The more
I used Groovy, the more I replaced runtime metaprogramming with AST
xforms. The main reason *was* performance, but also static checking.
So if you consider that static type checking is a must have feature
(as I do think, and comments to the announcement like "this is
awesome, exactly what I was waiting for" or "if static compilation
comes to Groovy, I'd definitely use it in place of Scala" make me
think we go in the right direction), then it is to me going halfway
not to statically compile and propose optimized bytecode. If code is
statically checked, then you definitely loose, for the parts that are
statically checked, the ability to go dynamic... If you can't use
dynamics, then static compilation makes sense. This is what you fear,
but this is exactly one feature I missed for years in Groovy: a less
verbose Java with compile time metaprogramming and comparable runtime
performance. This absolutely doesn't mean that this should be the
*default* behaviour, and this is why we chose to implement
@TypeChecked as an annotation, which could be used by other AST xforms
requiring type inference, and eventually by a static compiler.
Deciding whether we should also propose a static compiler or not
requires at least, IMHO, an experiment. If we follow the target
release plan for 2.0, then static compilation experiments should start
quickly, but this is another debate.

One of your key points was that you can use Java when you need
performance, and Groovy when you need dynamics. This is true, but this
is missing the fact that you may want to have everything written in
Groovy without a single line of dynamic code. In practice, for having
done this kind of development for 5 years, I can tell that mixing Java
and Groovy code is often not that easy (mixed mode, stub generation
failures, maven plugin, ...), and there are places where writing a
class in Java for performance, and the other one in Groovy for
expressiveness is a nonsense. If you could use one language, why
wouldn't you ? It's even worse when you are obliged to split a class
-or a method- into multiple ones for performance reasons. Think of
closures, for example... You fear that Groovy becomes a "failed Java
8", but I fear more that Java 8 doesn't go in Groovy's direction. We
also used, though it's true with less experience, Grails as a web
framework. And while productivity increased sensitively, the
developers kept complaining about the lack of static checking.

I really think Groovy is awesome because it offers two key aspects :
   * a Java-like syntax which makes the learning curve almost null (to
be compared with other JVM languages)
   * the ability to use dynamics

Not every people like dynamic languages. I do, you do, and lots of
people on this ML do. However, in terms of JVM scripting languages,
there are not so many alternatives. I honestly think Groovy has
something to propose here with static type checking and, for
performance reasons, static compilation. What I fear is that if we do
not go in that direction, the true vocal people, those from Scala,
Dart, ... will turn Groovy into a niche language.
>
> Turning Groovy into a mish-mash language trying to kowtow to the wants
> of a disparate and conflicting set of requirements seems like a recipe
> for the demise of the language.
>
> Groovy should not and should not even try to be a better Java.  It is a
> symbiotic partner bringing different capabilities.  This is Groovy's
> USP, and its sole reason for existing.
>

--
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

aalmiray
In reply to this post by Russel Winder
+1 spot on as always Russel!

However I also agree with Graeme in one case: bypassing the MOP in a particular context. We have had suggestions for a @TypeChecked or @Java AST xform that simply instructs the compiler to generate Java compliant byte code instead of groovy byte code. For me that would be more than enough.

A static type checker (a.k.a. grumpy mode) is desirable and if available in the form of a sweet gradle plugin I would gladly use it without further questioning. In the meantime there's Codenarc.

Adding a static compilation feature is a feature that may fracture the community in two camps, in a similar vein as it happens with Scala (whether you do pick the 'pureness' of FP over OO or not (see the Option vs Box debate with a bucket of popcorn for example)).

Russel Winder wrote
My fear here is that the direction of Groovy panders to the static type
adherents who despise all dynamic languages, and are very vocal in
damning Groovy because it is not Java, Scala, Kotlin, Ceylon.

I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
language to use as a complement to Java.  For performance critical
sections of code I use Java.  For dynamic components I use Groovy.  This
element of purity leads to clean and clear models of use.  This is an
easy sell in the training, take up and leveraging games.

Turning Groovy into a mish-mash language trying to kowtow to the wants
of a disparate and conflicting set of requirements seems like a recipe
for the demise of the language.

Groovy should not and should not even try to be a better Java.  It is a
symbiotic partner bringing different capabilities.  This is Groovy's
USP, and its sole reason for existing.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

tim yates-2
In reply to this post by Johnny Jian-2

Having a way to embed Java code straight into a Groovy script/class would be amazing. Like dropping to an asm block in my good old Delphi days

and if this worked, I guess there's no reason we couldn't have @Clojure, etc ;-)

Tim

On 11 Nov 2011 17:35, "Jian Hengyi" <[hidden email]> wrote:
Hi all,

I want to say something about my thoughts on static type checking and static compilation.

I think static type checking is a great idea. I view it as an opposite to the @SuppressWarnings annotation in Java which turns off the warnings from the compiler, while @TypeChecked turns on the warnings/errors from the compiler. And it is the savior for typos.

On the other hand, static compilation sounds like a bad idea to me, because it changes the semantics of groovy (groovy++ is an example). IMO, groovy should be always dynamic.

I think there are only two reasons for static compilation: performance and avoiding metaclass (as we do in gmock). However, can static groovy faster than pure java? And can it be more explicit to avoid metaclass than writing in java?

All the users need is just an easy way to embed java code into groovy code: a "java { ... }" block or a @Java AST transformation, instead of a separated java class. I cannot recall any desire for static groovy on the mailing list, but for the @Java AST transformation. If you ask a java programmer who is interested in groovy, which will he choose between static groovy and embedding java code, I bet the later one.

I already have an implementation approach in my mind, but I am not familiar with compilers, so I don't know where to start.

Let's say that we have a groovy class with @Java:

class Foo {
  @Java
  public void bar() { ... }
}

will be transformed into:

class Foo {
  private Foo$Java $java = new Foo$Java(this)
  public void bar() { $java.bar() }
}
// and a java class
class Foo$Java {
  ...
  public void bar() { ... }
}

then a joint compilation is all we need.

I remember that Jochen mentioned that there will be an syntax conflict between groovy and java. But how can groovy++ do so while it introduces some new grammars? If indeed we cannot handle the conflict, it is actually not a big deal as groovy supports almost all syntax of java, so just, for example, disallow java style array initialization.

Johnny
2011-11-12

On Fri, Nov 11, 2011 at 9:27 PM, Cédric Champeau <[hidden email]> wrote:
Hi Russel!
Le 11/11/2011 10:59, Russel Winder a écrit :
>
> My fear here is that the direction of Groovy panders to the static type
> adherents who despise all dynamic languages, and are very vocal in
> damning Groovy because it is not Java, Scala, Kotlin, Ceylon.

Well, looking at the answers to your email, it looks like it's more
the dynamic folks who are more vocal on this list :)
>
>
> I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
> language to use as a complement to Java.  For performance critical
> sections of code I use Java.  For dynamic components I use Groovy.  This
> element of purity leads to clean and clear models of use.  This is an
> easy sell in the training, take up and leveraging games.

I understand (and respect) your opinion, but I think it is biaised.
Groovy is not *only* a dynamic language. It is:
   a. an extension to Java (not meant to replace it, but work nicely with it)
   b. a dynamic language
   c. a scripting language
   d. an OOP language with functional features

After having worked with Groovy for a few years, with different people
with different opinions regarding static checking, dynamic languages
and so on, I can tell that conciseness and syntax matters. Many people
already use Groovy "as a Java with a better syntax". This is not
future, this is a fact. Those people do not use (or in very rare
occasions) the dynamic features of Groovy. They like the language
because it removes most of the verbosity from Java, but keeping a
syntax which is very close to Java. In my past company, I reviewed
code written in Groovy not by me, but by either Java specialists or
beginners, and figured out that almost none used dynamic features. In
fact there were two common usages:
   - scripting
   - DSLs

In the first case, most of errors were due to typos and leak of static
type checking. In the second case, I can speak properly because I had
written a text extraction engine which used Groovy as a DSL support
language. First, I started with runtime metaprogramming, then quickly
moved to compile time metaprogramming (AST transformations). The more
I used Groovy, the more I replaced runtime metaprogramming with AST
xforms. The main reason *was* performance, but also static checking.
So if you consider that static type checking is a must have feature
(as I do think, and comments to the announcement like "this is
awesome, exactly what I was waiting for" or "if static compilation
comes to Groovy, I'd definitely use it in place of Scala" make me
think we go in the right direction), then it is to me going halfway
not to statically compile and propose optimized bytecode. If code is
statically checked, then you definitely loose, for the parts that are
statically checked, the ability to go dynamic... If you can't use
dynamics, then static compilation makes sense. This is what you fear,
but this is exactly one feature I missed for years in Groovy: a less
verbose Java with compile time metaprogramming and comparable runtime
performance. This absolutely doesn't mean that this should be the
*default* behaviour, and this is why we chose to implement
@TypeChecked as an annotation, which could be used by other AST xforms
requiring type inference, and eventually by a static compiler.
Deciding whether we should also propose a static compiler or not
requires at least, IMHO, an experiment. If we follow the target
release plan for 2.0, then static compilation experiments should start
quickly, but this is another debate.

One of your key points was that you can use Java when you need
performance, and Groovy when you need dynamics. This is true, but this
is missing the fact that you may want to have everything written in
Groovy without a single line of dynamic code. In practice, for having
done this kind of development for 5 years, I can tell that mixing Java
and Groovy code is often not that easy (mixed mode, stub generation
failures, maven plugin, ...), and there are places where writing a
class in Java for performance, and the other one in Groovy for
expressiveness is a nonsense. If you could use one language, why
wouldn't you ? It's even worse when you are obliged to split a class
-or a method- into multiple ones for performance reasons. Think of
closures, for example... You fear that Groovy becomes a "failed Java
8", but I fear more that Java 8 doesn't go in Groovy's direction. We
also used, though it's true with less experience, Grails as a web
framework. And while productivity increased sensitively, the
developers kept complaining about the lack of static checking.

I really think Groovy is awesome because it offers two key aspects :
   * a Java-like syntax which makes the learning curve almost null (to
be compared with other JVM languages)
   * the ability to use dynamics

Not every people like dynamic languages. I do, you do, and lots of
people on this ML do. However, in terms of JVM scripting languages,
there are not so many alternatives. I honestly think Groovy has
something to propose here with static type checking and, for
performance reasons, static compilation. What I fear is that if we do
not go in that direction, the true vocal people, those from Scala,
Dart, ... will turn Groovy into a niche language.
>
> Turning Groovy into a mish-mash language trying to kowtow to the wants
> of a disparate and conflicting set of requirements seems like a recipe
> for the demise of the language.
>
> Groovy should not and should not even try to be a better Java.  It is a
> symbiotic partner bringing different capabilities.  This is Groovy's
> USP, and its sole reason for existing.
>

--
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Jon Cox
In reply to this post by Cédric Champeau


> Le 11/11/2011 10:59, Russel Winder a ?crit :
> >
> > My fear here is that the direction of Groovy panders to the static type
> > adherents who despise all dynamic languages, and are very vocal in
> > damning Groovy because it is not Java, Scala, Kotlin, Ceylon.
>
> Well, looking at the answers to your email, it looks like it's more
> the dynamic folks who are more vocal on this list :)


   You'd be right to argue that this way of thinking leads to
   a language that's someone non-optimal as a "pure" compiled
   or "pure" dynamic language.  However, language design is
   plainly about balancing a host of concerns.  In many cases,
   dynamic & static approaches seem like they be made to coexist
   pretty well.  

   What we've seen is that many people really don't want to
   keep current on a large number of different languages,
   or simply can't... or it turns the build into a PITA.
   They want to learn one really well, and then use it in
   as many places as possible.  
   
   This perspective tends to be undervalued on a mailing
   list populated by people that actually like learning new
   languages all the time, and that do it well.  Unfortunately,
   most folks are not like that.

   Being able to add efficiency to Groovy code in a progressive
   way by using/avoiding various constraints/features adds a
   huge amount of breadth & value to the language.


> > I don't want Groovy to be a failed Java 8 wannabee. ?I want a dynamic
> > language to use as a complement to Java. ?For performance critical
> > sections of code I use Java. ?For dynamic components I use Groovy. ?This
> > element of purity leads to clean and clear models of use. ?This is an
> > easy sell in the training, take up and leveraging games.



  Put as that kind of "Sophie's Choice", I'd agree completely.
  However, I think it's a false choice.  
 


> I understand (and respect) your opinion, but I think it is biaised.
> Groovy is not *only* a dynamic language. It is:
> ? ?a. an extension to Java (not meant to replace it, but work nicely with it)
> ? ?b. a dynamic language
> ? ?c. a scripting language
> ? ?d. an OOP language with functional features
>
> After having worked with Groovy for a few years, with different people
> with different opinions regarding static checking, dynamic languages
> and so on, I can tell that conciseness and syntax matters. Many people
> already use Groovy "as a Java with a better syntax". This is not
> future, this is a fact.


   I agree.

   Relegating Groovy to a wanabee Java 8 misses the point that
   for the most part, Groovy already "feels pretty good", so
   it's not a wannabe -- it already is.  



> Those people do not use (or in very rare
> occasions) the dynamic features of Groovy. They like the language
> because it removes most of the verbosity from Java, but keeping a
> syntax which is very close to Java. In my past company, I reviewed
> code written in Groovy not by me, but by either Java specialists or
> beginners, and figured out that almost none used dynamic features. In
> fact there were two common usages:
> ? ?- scripting
> ? ?- DSLs
>
> In the first case, most of errors were due to typos and leak of static
> type checking. In the second case, I can speak properly because I had
> written a text extraction engine which used Groovy as a DSL support
> language. First, I started with runtime metaprogramming, then quickly
> moved to compile time metaprogramming (AST transformations). The more
> I used Groovy, the more I replaced runtime metaprogramming with AST
> xforms. The main reason *was* performance, but also static checking.
> So if you consider that static type checking is a must have feature
> (as I do think, and comments to the announcement like "this is
> awesome, exactly what I was waiting for" or "if static compilation
> comes to Groovy, I'd definitely use it in place of Scala" make me
> think we go in the right direction), then it is to me going halfway
> not to statically compile and propose optimized bytecode. If code is
> statically checked, then you definitely loose, for the parts that are
> statically checked, the ability to go dynamic... If you can't use
> dynamics, then static compilation makes sense. This is what you fear,
> but this is exactly one feature I missed for years in Groovy: a less
> verbose Java with compile time metaprogramming and comparable runtime
> performance. This absolutely doesn't mean that this should be the
> *default* behaviour, and this is why we chose to implement
> @TypeChecked as an annotation, which could be used by other AST xforms
> requiring type inference, and eventually by a static compiler.
> Deciding whether we should also propose a static compiler or not
> requires at least, IMHO, an experiment. If we follow the target
> release plan for 2.0, then static compilation experiments should start
> quickly, but this is another debate.



  Great summary.


> One of your key points was that you can use Java when you need
> performance, and Groovy when you need dynamics. This is true, but this
> is missing the fact that you may want to have everything written in
> Groovy without a single line of dynamic code. In practice, for having
> done this kind of development for 5 years, I can tell that mixing Java
> and Groovy code is often not that easy (mixed mode, stub generation
> failures, maven plugin, ...), and there are places where writing a
> class in Java for performance, and the other one in Groovy for
> expressiveness is a nonsense. If you could use one language, why
> wouldn't you ? It's even worse when you are obliged to split a class
> -or a method- into multiple ones for performance reasons. Think of
> closures, for example... You fear that Groovy becomes a "failed Java
> 8", but I fear more that Java 8 doesn't go in Groovy's direction. We
> also used, though it's true with less experience, Grails as a web
> framework. And while productivity increased sensitively, the
> developers kept complaining about the lack of static checking.
>
> I really think Groovy is awesome because it offers two key aspects :
> ? ?* a Java-like syntax which makes the learning curve almost null (to
> be compared with other JVM languages)
> ? ?* the ability to use dynamics
>
> Not every people like dynamic languages. I do, you do, and lots of
> people on this ML do. However, in terms of JVM scripting languages,
> there are not so many alternatives. I honestly think Groovy has
> something to propose here with static type checking and, for
> performance reasons, static compilation. What I fear is that if we do
> not go in that direction, the true vocal people, those from Scala,
> Dart, ... will turn Groovy into a niche language.


   I'm not so much worried about that because the more purely
   static languages can't compete with more dynamic ones in
   terms of sheer ease & speed of development.  

   What would marginalize Groovy is if a language was able to span
   the range of dynamic & static trade-offs more elegantly...
   and also had most of Groovy's "nice overall feel".

   If Groovy gets there first, it would be a very tough act to follow.



> > Turning Groovy into a mish-mash language trying to kowtow to the wants
> > of a disparate and conflicting set of requirements seems like a recipe
> > for the demise of the language.
> >
> > Groovy should not and should not even try to be a better Java. ?It is a
> > symbiotic partner bringing different capabilities. ?This is Groovy's
> > USP, and its sole reason for existing.


   This begs the question though.  The challenge is to give Groovy
   more static (or optionally static) features, yet do so in a way
   that doesn't feel too icky.  Focusing on "purity" feels wrong;
   we should be focusing on ease, efficiency, and systemic complexity
   (not just language complexity).   Punting to another language
   is exactly that -- punting.  
   

                        Regards,
                        -Jon

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Jochen Theodorou
In reply to this post by aalmiray
Am 11.11.2011 19:58, schrieb aalmiray:
> +1 spot on as always Russel!
>
> However I also agree with Graeme in one case: bypassing the MOP in a
> particular context. We have had suggestions for a @TypeChecked or @Java AST
> xform that simply instructs the compiler to generate Java compliant byte
> code instead of groovy byte code. For me that would be more than enough.

but that is the static compilation we are talking of.. is there maybe a
misundestanding?

> A static type checker (a.k.a. grumpy mode) is desirable and if available in
> the form of a sweet gradle plugin I would gladly use it without further
> questioning. In the meantime there's Codenarc.

the static type checker will not replace codenarc, it will help codenarc.

bye blackdrag

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Merlyn Albery-Speyer
In reply to this post by Russel Winder

+1

On Nov 11, 2011 1:59 AM, "Russel Winder" <[hidden email]> wrote:
My fear here is that the direction of Groovy panders to the static type
adherents who despise all dynamic languages, and are very vocal in
damning Groovy because it is not Java, Scala, Kotlin, Ceylon.

I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
language to use as a complement to Java.  For performance critical
sections of code I use Java.  For dynamic components I use Groovy.  This
element of purity leads to clean and clear models of use.  This is an
easy sell in the training, take up and leveraging games.

Turning Groovy into a mish-mash language trying to kowtow to the wants
of a disparate and conflicting set of requirements seems like a recipe
for the demise of the language.

Groovy should not and should not even try to be a better Java.  It is a
symbiotic partner bringing different capabilities.  This is Groovy's
USP, and its sole reason for existing.

--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Johnny Jian-2
In reply to this post by Jochen Theodorou
On Sat, Nov 12, 2011 at 4:31 AM, Jochen Theodorou <[hidden email]> wrote:
Am 11.11.2011 19:58, schrieb aalmiray:

+1 spot on as always Russel!

However I also agree with Graeme in one case: bypassing the MOP in a
particular context. We have had suggestions for a @TypeChecked or @Java AST
xform that simply instructs the compiler to generate Java compliant byte
code instead of groovy byte code. For me that would be more than enough.

but that is the static compilation we are talking of.. is there maybe a misundestanding?


He was talking about my suggestion of allowing embedding java code instead of static compilation for groovy.

Johnny
2011-11-12
 

A static type checker (a.k.a. grumpy mode) is desirable and if available in
the form of a sweet gradle plugin I would gladly use it without further
questioning. In the meantime there's Codenarc.

the static type checker will not replace codenarc, it will help codenarc.

bye blackdrag


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Johnny Jian-2
In reply to this post by Jon Cox
On Sat, Nov 12, 2011 at 4:09 AM, Jon Cox <[hidden email]> wrote:


> Le 11/11/2011 10:59, Russel Winder a ?crit :
> >
> > My fear here is that the direction of Groovy panders to the static type
> > adherents who despise all dynamic languages, and are very vocal in
> > damning Groovy because it is not Java, Scala, Kotlin, Ceylon.
>
> Well, looking at the answers to your email, it looks like it's more
> the dynamic folks who are more vocal on this list :)


  You'd be right to argue that this way of thinking leads to
  a language that's someone non-optimal as a "pure" compiled
  or "pure" dynamic language.  However, language design is
  plainly about balancing a host of concerns.  In many cases,
  dynamic & static approaches seem like they be made to coexist
  pretty well.

  What we've seen is that many people really don't want to
  keep current on a large number of different languages,
  or simply can't... or it turns the build into a PITA.
  They want to learn one really well, and then use it in
  as many places as possible.

  This perspective tends to be undervalued on a mailing
  list populated by people that actually like learning new
  languages all the time, and that do it well.  Unfortunately,
  most folks are not like that.

  Being able to add efficiency to Groovy code in a progressive
  way by using/avoiding various constraints/features adds a
  huge amount of breadth & value to the language.


IMO, syntax and semantic make a language. Static groovy is actually a different language from dynamic groovy, which has the same grammar but different semantic. So your point of static groovy preventing from the pain of multiple languages doesn't stand. What's more, I think static groovy will make things even worst. People will have to think about the different meanings of the same statement in static groovy and dynamic groovy, although they have the same grammar.

My suggestion: keep the static compilation as an extension to the normal groovy, just like groovy++.

One more thing, my suggested solution of embedding java code can also solve the problem of build with multiple languages, because the groovy code and java code are both written in the same file.

Johnny
2011-11-12
 

> > I don't want Groovy to be a failed Java 8 wannabee. ?I want a dynamic
> > language to use as a complement to Java. ?For performance critical
> > sections of code I use Java. ?For dynamic components I use Groovy. ?This
> > element of purity leads to clean and clear models of use. ?This is an
> > easy sell in the training, take up and leveraging games.



 Put as that kind of "Sophie's Choice", I'd agree completely.
 However, I think it's a false choice.



> I understand (and respect) your opinion, but I think it is biaised.
> Groovy is not *only* a dynamic language. It is:
> ? ?a. an extension to Java (not meant to replace it, but work nicely with it)
> ? ?b. a dynamic language
> ? ?c. a scripting language
> ? ?d. an OOP language with functional features
>
> After having worked with Groovy for a few years, with different people
> with different opinions regarding static checking, dynamic languages
> and so on, I can tell that conciseness and syntax matters. Many people
> already use Groovy "as a Java with a better syntax". This is not
> future, this is a fact.


  I agree.

  Relegating Groovy to a wanabee Java 8 misses the point that
  for the most part, Groovy already "feels pretty good", so
  it's not a wannabe -- it already is.



> Those people do not use (or in very rare
> occasions) the dynamic features of Groovy. They like the language
> because it removes most of the verbosity from Java, but keeping a
> syntax which is very close to Java. In my past company, I reviewed
> code written in Groovy not by me, but by either Java specialists or
> beginners, and figured out that almost none used dynamic features. In
> fact there were two common usages:
> ? ?- scripting
> ? ?- DSLs
>
> In the first case, most of errors were due to typos and leak of static
> type checking. In the second case, I can speak properly because I had
> written a text extraction engine which used Groovy as a DSL support
> language. First, I started with runtime metaprogramming, then quickly
> moved to compile time metaprogramming (AST transformations). The more
> I used Groovy, the more I replaced runtime metaprogramming with AST
> xforms. The main reason *was* performance, but also static checking.
> So if you consider that static type checking is a must have feature
> (as I do think, and comments to the announcement like "this is
> awesome, exactly what I was waiting for" or "if static compilation
> comes to Groovy, I'd definitely use it in place of Scala" make me
> think we go in the right direction), then it is to me going halfway
> not to statically compile and propose optimized bytecode. If code is
> statically checked, then you definitely loose, for the parts that are
> statically checked, the ability to go dynamic... If you can't use
> dynamics, then static compilation makes sense. This is what you fear,
> but this is exactly one feature I missed for years in Groovy: a less
> verbose Java with compile time metaprogramming and comparable runtime
> performance. This absolutely doesn't mean that this should be the
> *default* behaviour, and this is why we chose to implement
> @TypeChecked as an annotation, which could be used by other AST xforms
> requiring type inference, and eventually by a static compiler.
> Deciding whether we should also propose a static compiler or not
> requires at least, IMHO, an experiment. If we follow the target
> release plan for 2.0, then static compilation experiments should start
> quickly, but this is another debate.



 Great summary.


> One of your key points was that you can use Java when you need
> performance, and Groovy when you need dynamics. This is true, but this
> is missing the fact that you may want to have everything written in
> Groovy without a single line of dynamic code. In practice, for having
> done this kind of development for 5 years, I can tell that mixing Java
> and Groovy code is often not that easy (mixed mode, stub generation
> failures, maven plugin, ...), and there are places where writing a
> class in Java for performance, and the other one in Groovy for
> expressiveness is a nonsense. If you could use one language, why
> wouldn't you ? It's even worse when you are obliged to split a class
> -or a method- into multiple ones for performance reasons. Think of
> closures, for example... You fear that Groovy becomes a "failed Java
> 8", but I fear more that Java 8 doesn't go in Groovy's direction. We
> also used, though it's true with less experience, Grails as a web
> framework. And while productivity increased sensitively, the
> developers kept complaining about the lack of static checking.
>
> I really think Groovy is awesome because it offers two key aspects :
> ? ?* a Java-like syntax which makes the learning curve almost null (to
> be compared with other JVM languages)
> ? ?* the ability to use dynamics
>
> Not every people like dynamic languages. I do, you do, and lots of
> people on this ML do. However, in terms of JVM scripting languages,
> there are not so many alternatives. I honestly think Groovy has
> something to propose here with static type checking and, for
> performance reasons, static compilation. What I fear is that if we do
> not go in that direction, the true vocal people, those from Scala,
> Dart, ... will turn Groovy into a niche language.


  I'm not so much worried about that because the more purely
  static languages can't compete with more dynamic ones in
  terms of sheer ease & speed of development.

  What would marginalize Groovy is if a language was able to span
  the range of dynamic & static trade-offs more elegantly...
  and also had most of Groovy's "nice overall feel".

  If Groovy gets there first, it would be a very tough act to follow.



> > Turning Groovy into a mish-mash language trying to kowtow to the wants
> > of a disparate and conflicting set of requirements seems like a recipe
> > for the demise of the language.
> >
> > Groovy should not and should not even try to be a better Java. ?It is a
> > symbiotic partner bringing different capabilities. ?This is Groovy's
> > USP, and its sole reason for existing.


  This begs the question though.  The challenge is to give Groovy
  more static (or optionally static) features, yet do so in a way
  that doesn't feel too icky.  Focusing on "purity" feels wrong;
  we should be focusing on ease, efficiency, and systemic complexity
  (not just language complexity).   Punting to another language
  is exactly that -- punting.


                       Regards,
                       -Jon

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



123
Loading...