Groovy performance: what to do

[Alex Tkachman]

Hi Groovy Developers!

As many of you know I spent almost last 8 months (since July) working
mostly on different aspects of Groovy performance. And results so far
are very good - each new version are noticeably faster then previous
one.

But you know what - I feel myself like an idiot.

The problem we try to solve can be formulated very simply
- we have piece of code, which is effectlvely statically typed (either
typed already or can become typed without to much problems for
developer because he knows that nothing dynamic is involved)
- we forget almost all we know about types during compilation because
we assume that everything can be dynamicly changed at any momemt
- we try to achieve same performance as Java has by doing amounts of
very complicated tricks on runtime

After 4th attempt to rewrite call sites optimization and avoid some
very tricky bugs with EMC and categories on multi-threading I felt
that it is not the best way to spend my life.

At this point I remind myself well-known rule that 95% of performance
problems come from 5% of code. Well, we can argue about exact figures
- some people say 99-1, some 90-10, some 80-20 and I my personal
experience during many years is 95-5 but I don't think it is really
matter.

What is really matter is that instead of runtime optimizing everything
without help of developer I (as developer) would prefer to help
compiler to optimize 5% of code, which is performance critical for me.

So I did simple experiment
- I introduced annotation

@Retention(RetentionPolicy.SOURCE)
@Target({ElementType.TYPE,ElementType.METHOD,ElementType.CONSTRUCTOR})
public @interface Typed {
    public enum TypePolicy {
         Dynamicly,    // traditional Groovy, no resolve
         Strictly,           // traditional Java, full resolve required
         SemiStrictly   // resolve and call statically what you can
and call the rest dynamically
   }

    TypePolicy value () default TypePolicy.Strictly;
}

- I prototyped compiler modification to use for static resolve (for
Strictly and SemiStrictly) both type information, DGM methods and
categories in use
- I prototyped work with primitives for  Strictly and SemiStrictly

- I experimented with just one script spectralnorm, which is my huge
headache last weeks and which is much much slower then Java
counterpart.

- By annotating just one method with @Typed it becomes only twice
slower compare to Java

- By annotating two methods it becomes only 5% slower than Java

Is it surprise? Of course, not.

Does it show right way to go? I believe so. Instead of fighting for
optimization of code, which is assumed to be dynamic (read can't be
really optimized) we give tool for developer to choose when he want to
optimize.

Someone can argue that developer can always use Java, when he needs
piece of statically typed code. There are several reasons why this is
wrong
- we seriously limit his freedom to develop
- if he needs just 1 or 2 statically typed methods, why to add another
Java class

Now when Groovy becomes more and more popular and used together with
tons of existing Java code we hear a lot of complains from users and
developers (like recent messages from Peter and Graeme) regarding need
for compile time (and even IDE level) type check instead od runtime.
The beuty of my approach is it also gives ability to mark  piece of
code as type checked.

I believe if we choose to implement this program Groovy will become
even stronger and appealing for Java developers.

What do you think?

Best regards
Alex

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

    http://xircles.codehaus.org/manage_email

[Steven Devijver]

Hey Alex,

Actually, I wanted to propose something similar before. I'm very happy
you got this working!

I think the annotation is great. Do you think there could also be a
syntax that does the same, like:

assert strict { 1 + 1 } == 2

Thanks

Steven

On Feb 19, 2008 11:10 AM, Alex Tkachman <alex.tkachman@...> wrote:

> Hi Groovy Developers!
>
> As many of you know I spent almost last 8 months (since July) working
> mostly on different aspects of Groovy performance. And results so far
> are very good - each new version are noticeably faster then previous
> one.
>
> But you know what - I feel myself like an idiot.
>
> The problem we try to solve can be formulated very simply
> - we have piece of code, which is effectlvely statically typed (either
> typed already or can become typed without to much problems for
> developer because he knows that nothing dynamic is involved)
> - we forget almost all we know about types during compilation because
> we assume that everything can be dynamicly changed at any momemt
> - we try to achieve same performance as Java has by doing amounts of
> very complicated tricks on runtime
>
> After 4th attempt to rewrite call sites optimization and avoid some
> very tricky bugs with EMC and categories on multi-threading I felt
> that it is not the best way to spend my life.
>
> At this point I remind myself well-known rule that 95% of performance
> problems come from 5% of code. Well, we can argue about exact figures
> - some people say 99-1, some 90-10, some 80-20 and I my personal
> experience during many years is 95-5 but I don't think it is really
> matter.
>
> What is really matter is that instead of runtime optimizing everything
> without help of developer I (as developer) would prefer to help
> compiler to optimize 5% of code, which is performance critical for me.
>
> So I did simple experiment
> - I introduced annotation
>
> @Retention(RetentionPolicy.SOURCE)
> @Target({ElementType.TYPE,ElementType.METHOD,ElementType.CONSTRUCTOR})
> public @interface Typed {
>     public enum TypePolicy {
>          Dynamicly,    // traditional Groovy, no resolve
>          Strictly,           // traditional Java, full resolve required
>          SemiStrictly   // resolve and call statically what you can
> and call the rest dynamically
>    }
>
>     TypePolicy value () default TypePolicy.Strictly;
> }
>
> - I prototyped compiler modification to use for static resolve (for
> Strictly and SemiStrictly) both type information, DGM methods and
> categories in use
> - I prototyped work with primitives for  Strictly and SemiStrictly
>
> - I experimented with just one script spectralnorm, which is my huge
> headache last weeks and which is much much slower then Java
> counterpart.
>
> - By annotating just one method with @Typed it becomes only twice
> slower compare to Java
>
> - By annotating two methods it becomes only 5% slower than Java
>
> Is it surprise? Of course, not.
>
> Does it show right way to go? I believe so. Instead of fighting for
> optimization of code, which is assumed to be dynamic (read can't be
> really optimized) we give tool for developer to choose when he want to
> optimize.
>
> Someone can argue that developer can always use Java, when he needs
> piece of statically typed code. There are several reasons why this is
> wrong
> - we seriously limit his freedom to develop
> - if he needs just 1 or 2 statically typed methods, why to add another
> Java class
>
> Now when Groovy becomes more and more popular and used together with
> tons of existing Java code we hear a lot of complains from users and
> developers (like recent messages from Peter and Graeme) regarding need
> for compile time (and even IDE level) type check instead od runtime.
> The beuty of my approach is it also gives ability to mark  piece of
> code as type checked.
>
> I believe if we choose to implement this program Groovy will become
> even stronger and appealing for Java developers.
>
> What do you think?
>
> Best regards
> Alex
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Alexandru Popescu ☀]

On Feb 19, 2008 12:10 PM, Alex Tkachman <alex.tkachman@...> wrote:

> Hi Groovy Developers!
>
> As many of you know I spent almost last 8 months (since July) working
> mostly on different aspects of Groovy performance. And results so far
> are very good - each new version are noticeably faster then previous
> one.
>
> But you know what - I feel myself like an idiot.
>
> The problem we try to solve can be formulated very simply
> - we have piece of code, which is effectlvely statically typed (either
> typed already or can become typed without to much problems for
> developer because he knows that nothing dynamic is involved)
> - we forget almost all we know about types during compilation because
> we assume that everything can be dynamicly changed at any momemt
> - we try to achieve same performance as Java has by doing amounts of
> very complicated tricks on runtime
>
> After 4th attempt to rewrite call sites optimization and avoid some
> very tricky bugs with EMC and categories on multi-threading I felt
> that it is not the best way to spend my life.
>
> At this point I remind myself well-known rule that 95% of performance
> problems come from 5% of code. Well, we can argue about exact figures
> - some people say 99-1, some 90-10, some 80-20 and I my personal
> experience during many years is 95-5 but I don't think it is really
> matter.
>
> What is really matter is that instead of runtime optimizing everything
> without help of developer I (as developer) would prefer to help
> compiler to optimize 5% of code, which is performance critical for me.
>
> So I did simple experiment
> - I introduced annotation
>
> @Retention(RetentionPolicy.SOURCE)
> @Target({ElementType.TYPE,ElementType.METHOD,ElementType.CONSTRUCTOR})
> public @interface Typed {
>     public enum TypePolicy {
>          Dynamicly,    // traditional Groovy, no resolve
>          Strictly,           // traditional Java, full resolve required
>          SemiStrictly   // resolve and call statically what you can
> and call the rest dynamically
>    }
>
>     TypePolicy value () default TypePolicy.Strictly;
> }
>
> - I prototyped compiler modification to use for static resolve (for
> Strictly and SemiStrictly) both type information, DGM methods and
> categories in use
> - I prototyped work with primitives for  Strictly and SemiStrictly
>
> - I experimented with just one script spectralnorm, which is my huge
> headache last weeks and which is much much slower then Java
> counterpart.
>
> - By annotating just one method with @Typed it becomes only twice
> slower compare to Java
>
> - By annotating two methods it becomes only 5% slower than Java
>
> Is it surprise? Of course, not.
>
> Does it show right way to go? I believe so. Instead of fighting for
> optimization of code, which is assumed to be dynamic (read can't be
> really optimized) we give tool for developer to choose when he want to
> optimize.
>
> Someone can argue that developer can always use Java, when he needs
> piece of statically typed code. There are several reasons why this is
> wrong
> - we seriously limit his freedom to develop
> - if he needs just 1 or 2 statically typed methods, why to add another
> Java class
>
> Now when Groovy becomes more and more popular and used together with
> tons of existing Java code we hear a lot of complains from users and
> developers (like recent messages from Peter and Graeme) regarding need
> for compile time (and even IDE level) type check instead od runtime.
> The beuty of my approach is it also gives ability to mark  piece of
> code as type checked.
>
> I believe if we choose to implement this program Groovy will become
> even stronger and appealing for Java developers.
>
> What do you think?
>
> Best regards
> Alex
>

Hi Alex,

First of all, I would like to thank you for the work to improve the
performance of Groovy. Your efforts are much appreciated!

Now, I see this problem in the following way:

1/ I do think that the current implementation (and I am referring here
to the 1.5 branch) of MOP + Categories is suboptimal. JRuby guys,
John's Ng and I think even Jython guys have found better ways to
handle these implementation details.

I know that rewriting this part might require a huge effort and most
probably will result in breaking changes. However, according to the
JRuby benchmarks, I think it is worth it. And by looking at other
popular languages (you mentioned at some point that you are very
familiar with Python), they have got the guts to introduce late
breaking changes that have lead to overall improvements (those being
about performance, stability or consistency of the language).
I do believe that Groovy should follow the same way and that the next
major version should have these part rewritten. Call it Groovy 2 or
Groovy 2k or whatever, but I strongly feel that this should be the
place where your and maybe others effort should go.

2/ As we have previously discussed, I also like the idea of letting
the developer decide on which parts he/she wants strict/dynamic
typing. And if this is the only option to get a huge performance
improvement for the 1.5 branch then I guess it may be worth to offer
this option to our users.

Concluding, for me the near future of Groovy depends a lot of the
language consistency and performance (and in a smaller measure to its
API stability -- remember I've said near future). I would like to have
a new version whose overall performance is improved thanks to
clarifying the details of the MOP/Categories implementation. And I do
believe that thanks to the consistency introduced by such a
reimplementation most of the people will be willing to switch to the
new version. However, for those that have invested a lot in the
current version, the solution you're suggesting may work (and I do
think it may be useful also in the next version).

bests,

./alex
--
.w( the_mindstorm )p.

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

    http://xircles.codehaus.org/manage_email

[Alex Tkachman]

I don't think we really need to go so deeply. I think method level
control is more then enough.
And I have very pure prototype, which works only for couple of test
scripts. To implement everything with great test coverage is job for
2-3 months

On Feb 19, 2008 1:38 PM, Steven Devijver <steven.devijver@...> wrote:

> Hey Alex,
>
> Actually, I wanted to propose something similar before. I'm very happy
> you got this working!
>
> I think the annotation is great. Do you think there could also be a
> syntax that does the same, like:
>
> assert strict { 1 + 1 } == 2
>
> Thanks
>
> Steven
>
>
> On Feb 19, 2008 11:10 AM, Alex Tkachman <alex.tkachman@...> wrote:
> > Hi Groovy Developers!
> >
> > As many of you know I spent almost last 8 months (since July) working
> > mostly on different aspects of Groovy performance. And results so far
> > are very good - each new version are noticeably faster then previous
> > one.
> >
> > But you know what - I feel myself like an idiot.
> >
> > The problem we try to solve can be formulated very simply
> > - we have piece of code, which is effectlvely statically typed (either
> > typed already or can become typed without to much problems for
> > developer because he knows that nothing dynamic is involved)
> > - we forget almost all we know about types during compilation because
> > we assume that everything can be dynamicly changed at any momemt
> > - we try to achieve same performance as Java has by doing amounts of
> > very complicated tricks on runtime
> >
> > After 4th attempt to rewrite call sites optimization and avoid some
> > very tricky bugs with EMC and categories on multi-threading I felt
> > that it is not the best way to spend my life.
> >
> > At this point I remind myself well-known rule that 95% of performance
> > problems come from 5% of code. Well, we can argue about exact figures
> > - some people say 99-1, some 90-10, some 80-20 and I my personal
> > experience during many years is 95-5 but I don't think it is really
> > matter.
> >
> > What is really matter is that instead of runtime optimizing everything
> > without help of developer I (as developer) would prefer to help
> > compiler to optimize 5% of code, which is performance critical for me.
> >
> > So I did simple experiment
> > - I introduced annotation
> >
> > @Retention(RetentionPolicy.SOURCE)
> > @Target({ElementType.TYPE,ElementType.METHOD,ElementType.CONSTRUCTOR})
> > public @interface Typed {
> >     public enum TypePolicy {
> >          Dynamicly,    // traditional Groovy, no resolve
> >          Strictly,           // traditional Java, full resolve required
> >          SemiStrictly   // resolve and call statically what you can
> > and call the rest dynamically
> >    }
> >
> >     TypePolicy value () default TypePolicy.Strictly;
> > }
> >
> > - I prototyped compiler modification to use for static resolve (for
> > Strictly and SemiStrictly) both type information, DGM methods and
> > categories in use
> > - I prototyped work with primitives for  Strictly and SemiStrictly
> >
> > - I experimented with just one script spectralnorm, which is my huge
> > headache last weeks and which is much much slower then Java
> > counterpart.
> >
> > - By annotating just one method with @Typed it becomes only twice
> > slower compare to Java
> >
> > - By annotating two methods it becomes only 5% slower than Java
> >
> > Is it surprise? Of course, not.
> >
> > Does it show right way to go? I believe so. Instead of fighting for
> > optimization of code, which is assumed to be dynamic (read can't be
> > really optimized) we give tool for developer to choose when he want to
> > optimize.
> >
> > Someone can argue that developer can always use Java, when he needs
> > piece of statically typed code. There are several reasons why this is
> > wrong
> > - we seriously limit his freedom to develop
> > - if he needs just 1 or 2 statically typed methods, why to add another
> > Java class
> >
> > Now when Groovy becomes more and more popular and used together with
> > tons of existing Java code we hear a lot of complains from users and
> > developers (like recent messages from Peter and Graeme) regarding need
> > for compile time (and even IDE level) type check instead od runtime.
> > The beuty of my approach is it also gives ability to mark  piece of
> > code as type checked.
> >
> > I believe if we choose to implement this program Groovy will become
> > even stronger and appealing for Java developers.
> >
> > What do you think?
> >
> > Best regards
> > Alex
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Patric Bechtel-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alex Tkachman schrieb am 19.02.2008 11:10:
> Hi Groovy Developers!
>
> What do you think?

I wholeheartedly support and second your idea. I felt already that there
was a need for something like this, just the right idea wasn't there yet.
Now, as I see your proposal, I feel it's the absolute right thing to do;
it would make a *lot* of people (including me) using Groovy for their
everyday work in bigger projects. For now, it was safety against
groovy-ness. That means, if a piece of code showed up to need more speed
then you had to forget closures, nice syntax et al.

All in all: This is a genius idea :) You saved my day!

- --
Patric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.5.2

iD8DBQFHurmrfGgGu8y7ypARAoVKAKDwjY8NgWR70A0PARARM+BCIwLA3wCgg+Gp
62xKeFQlJZ6rN3hOEpRoURw=
=nPAw
-----END PGP SIGNATURE-----

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

    http://xircles.codehaus.org/manage_email

[glaforge]

This is an interesting experiment.

You've done a great work so far on improving the performance of
Groovy, and Groovy 1.6 will bring Groovy ahead of the pack as the most
performant dynamic language for the JVM.

Congratulations for this work.

However, as this has been discussed on this list a few times already
or at the last Groovy Developer Conference, it's better and saner to
make Groovy the fastest dynamic language possible on the JVM by
creating the best second generation MOP, rather than by adding a few
hacks to make Groovy a more statically typed language.

What would happen if such a proposal was committed?
In a few months from now, all Groovy code samples we would come across
would be littered with @Typed annotations all around -- who remembers
the ugly @Property annotation making your Groovy beans ugly?
A few months later, and people will wonder why this is not the default
behavior and be applied to all possible methods or classes.
Groovy will become more and more statically typed, and for
"performance sake", we'd imagine other such hacks to make Groovy less
and less dynamic over time, or littered with ugly annotations.

Such a proposal would be a consent that we failed to make Groovy the
fastest dynamic language possible.
Have we really tried to make Groovy as fast as possible? Have we
implemented a second generation MOP yet? No.

Furthermore, even with such an annotation, this code path would always
be slower than raw Java anyway.

Remember that Groovy has not been conceived to replace Java, but as a
complement, an adjunct, an enhancer to Java.
It's a core value of the language and the project.
With the joint compiler, the ant tasks, the maven plugin, it's so easy
to just implement one additional Java class, that it is totally
seamless and transparent to mix Groovy and Java together.

When raw performance matter, using Java is simply the best option, and
nothing we could do would make the code faster than raw Java.

It doesn't mean that Groovy can't be made more performant than it is
today, on the contrary, it's time to work on MOP2 instead. So you can
focus your energy on something less frustrating if you so wish.

As discussed several times already, we should focus now on this new
Meta-Object Protocol, perhaps to make Groovy even more dynamic, but to
make it the faster possible dynamic language across all possible
platforms -- it's not an unrealistic goal to be faster than Ruby and
Python.

John Wilson and his experiments prove that even without call site
caching and similar techniques, we can be even more performant than we
are today with all these techniques applied. The Jython and JRuby
guys, as well as the guys on the JVM language list prove us that there
are better ways too.

If ever we recognize that this new architecture is a failure, we don't
even need to implement such annotation trick, as the simplest possible
way to make the code as performant as possible is to just implement a
few lines of Java code to make the overal performance right so that
all possible projects meet the expected stricter SLAs.

So, thanks a lot for this suggestion and experiment, but I think it's
not the right direction to take in terms of performance improvements,
but rather it's time we spend our time and energy on designing the
next generation dynamic system for Groovy.



On Tue, Feb 19, 2008 at 11:10 AM, Alex Tkachman <alex.tkachman@...> wrote:

> Hi Groovy Developers!
>
>  As many of you know I spent almost last 8 months (since July) working
>  mostly on different aspects of Groovy performance. And results so far
>  are very good - each new version are noticeably faster then previous
>  one.
>
>  But you know what - I feel myself like an idiot.
>
>  The problem we try to solve can be formulated very simply
>  - we have piece of code, which is effectlvely statically typed (either
>  typed already or can become typed without to much problems for
>  developer because he knows that nothing dynamic is involved)
>  - we forget almost all we know about types during compilation because
>  we assume that everything can be dynamicly changed at any momemt
>  - we try to achieve same performance as Java has by doing amounts of
>  very complicated tricks on runtime
>
>  After 4th attempt to rewrite call sites optimization and avoid some
>  very tricky bugs with EMC and categories on multi-threading I felt
>  that it is not the best way to spend my life.
>
>  At this point I remind myself well-known rule that 95% of performance
>  problems come from 5% of code. Well, we can argue about exact figures
>  - some people say 99-1, some 90-10, some 80-20 and I my personal
>  experience during many years is 95-5 but I don't think it is really
>  matter.
>
>  What is really matter is that instead of runtime optimizing everything
>  without help of developer I (as developer) would prefer to help
>  compiler to optimize 5% of code, which is performance critical for me.
>
>  So I did simple experiment
>  - I introduced annotation
>
>  @Retention(RetentionPolicy.SOURCE)
>  @Target({ElementType.TYPE,ElementType.METHOD,ElementType.CONSTRUCTOR})
>  public @interface Typed {
>     public enum TypePolicy {
>          Dynamicly,    // traditional Groovy, no resolve
>          Strictly,           // traditional Java, full resolve required
>          SemiStrictly   // resolve and call statically what you can
>  and call the rest dynamically
>    }
>
>     TypePolicy value () default TypePolicy.Strictly;
>  }
>
>  - I prototyped compiler modification to use for static resolve (for
>  Strictly and SemiStrictly) both type information, DGM methods and
>  categories in use
>  - I prototyped work with primitives for  Strictly and SemiStrictly
>
>  - I experimented with just one script spectralnorm, which is my huge
>  headache last weeks and which is much much slower then Java
>  counterpart.
>
>  - By annotating just one method with @Typed it becomes only twice
>  slower compare to Java
>
>  - By annotating two methods it becomes only 5% slower than Java
>
>  Is it surprise? Of course, not.
>
>  Does it show right way to go? I believe so. Instead of fighting for
>  optimization of code, which is assumed to be dynamic (read can't be
>  really optimized) we give tool for developer to choose when he want to
>  optimize.
>
>  Someone can argue that developer can always use Java, when he needs
>  piece of statically typed code. There are several reasons why this is
>  wrong
>  - we seriously limit his freedom to develop
>  - if he needs just 1 or 2 statically typed methods, why to add another
>  Java class
>
>  Now when Groovy becomes more and more popular and used together with
>  tons of existing Java code we hear a lot of complains from users and
>  developers (like recent messages from Peter and Graeme) regarding need
>  for compile time (and even IDE level) type check instead od runtime.
>  The beuty of my approach is it also gives ability to mark  piece of
>  code as type checked.
>
>  I believe if we choose to implement this program Groovy will become
>  even stronger and appealing for Java developers.
>
>  What do you think?
>
>  Best regards
>  Alex
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

    http://xircles.codehaus.org/manage_email

[glaforge]

On Tue, Feb 19, 2008 at 11:57 AM, Alexandru Popescu ☀
<the.mindstorm.mailinglist@...> wrote:

> [...]
>  2/ As we have previously discussed, I also like the idea of letting
>  the developer decide on which parts he/she wants strict/dynamic
>  typing. And if this is the only option to get a huge performance
>  improvement for the 1.5 branch then I guess it may be worth to offer
>  this option to our users.
>
>  Concluding, for me the near future of Groovy depends a lot of the
>  language consistency and performance (and in a smaller measure to its
>  API stability -- remember I've said near future). I would like to have
>  a new version whose overall performance is improved thanks to
>  clarifying the details of the MOP/Categories implementation. And I do
>  believe that thanks to the consistency introduced by such a
>  reimplementation most of the people will be willing to switch to the
>  new version. However, for those that have invested a lot in the
>  current version, the solution you're suggesting may work (and I do
>  think it may be useful also in the next version).

Even with the 1.5.x branch, it's so easy these days to add one single
additional Java class to fix the hotspots.

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

[Patric Bechtel-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guillaume Laforge schrieb am 19.02.2008 12:25:

Hi,

> This is an interesting experiment.
>
> However, as this has been discussed on this list a few times already
> or at the last Groovy Developer Conference, it's better and saner to
> make Groovy the fastest dynamic language possible on the JVM by
> creating the best second generation MOP, rather than by adding a few
> hacks to make Groovy a more statically typed language.
>
> What would happen if such a proposal was committed?
> In a few months from now, all Groovy code samples we would come across
> would be littered with @Typed annotations all around -- who remembers
> the ugly @Property annotation making your Groovy beans ugly?
> A few months later, and people will wonder why this is not the default
> behavior and be applied to all possible methods or classes.
> Groovy will become more and more statically typed, and for
> "performance sake", we'd imagine other such hacks to make Groovy less
> and less dynamic over time, or littered with ugly annotations.

I'm not sure if this is really true. So far, there's plenty of Java
programmers out there who would *love* to use Groovy if there was more
compile time checking involved. But, and I understand that, that's not
possible as long as everything is super-dynamic.
It's not that I don't appreciate that, it's very very nice. Really. But
as even a typo in a variable goes unnoticed by the compiler, it's
annoying compared to Java to prototype an algorithm.
So, sometimes, it would be nice to make the compiler more strict, so
that less things go unnoticed into runtime failures.
I can speak only for my colleagues and me, as we currently use yet
another "alternative" language for Java development, and as syntax is
already very similar, a switch to or coexistence with Groovy would be,
given the possibilities of Groovy, very nice.

To emphasize my point: It's less the speed (though welcome, but we are
not doing raw numeric calculations anyway), it's the convenience and the
confidence of getting the source through compile stage (we are not using
an IDE) and being able to concentrate onto the algorithm itself. Maybe
we should think about the @Typed annotation as tip to the compiler for
stricter checks? Or we rename it and leave it to future compiler
versions to optimize differently according to this setting?

At least, we have to pick up the majority of java programmers where they
currently are, and not where you wish them to be. I'm a strong advocate
of Groovy and use it wherever I can and urge others to do the same. But
given a bridge to static typed minds to get to Groovy dynamic worlds
would help them come over...

- --
Patric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.5.2

iD8DBQFHutQafGgGu8y7ypARAjJcAKCyBCk38eMcpWKONXpMXjVoQySzgQCfU9D9
i8PgPw8Us0MoIlRDnHweBPs=
=Nxy3
-----END PGP SIGNATURE-----

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

    http://xircles.codehaus.org/manage_email

[Gavin Grover]

----- Original Message ----From: Alex Tkachman
[...]

> Does it show right way to go? I believe so. Instead of fighting for
> optimization of code, which is assumed to be dynamic (read can't be
> really optimized) we give tool for developer to choose when he want to
> optimize.
>
> Someone can argue that developer can always use Java, when he needs
> piece of statically typed code. There are several reasons why this is
> wrong
> - we seriously limit his freedom to develop
> - if he needs just 1 or 2 statically typed methods, why to add another
> Java class
>

This would be good for those of us who took up Groovy without wanting to use Java again. No more semicolons and parentheses when all we need is more performance.

> Now when Groovy becomes more and more popular and used together with
> tons of existing Java code we hear a lot of complains from users and
> developers (like recent messages from Peter and Graeme) regarding need
> for compile time (and even IDE level) type check instead od runtime.
> The beuty of my approach is it also gives ability to mark  piece of
> code as type checked.
>
> I believe if we choose to implement this program Groovy will become
> even stronger and appealing for Java developers.

...and for those coming from non-Java backgrounds to dynamic languages who are evaluating Groovy, Ruby, and Python. This might tip the scales Groovy's way.


Cheers, Gavin Grover
gvgrover@...
gavingrover.blogspot.com




      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


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

    http://xircles.codehaus.org/manage_email

[Steven Devijver]

On Feb 19, 2008 2:05 PM, Patric Bechtel <patric.bechtel@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Guillaume Laforge schrieb am 19.02.2008 12:25:
>
> Hi,
>
> > This is an interesting experiment.
> >
> > However, as this has been discussed on this list a few times already
> > or at the last Groovy Developer Conference, it's better and saner to
> > make Groovy the fastest dynamic language possible on the JVM by
> > creating the best second generation MOP, rather than by adding a few
> > hacks to make Groovy a more statically typed language.
> >
> > What would happen if such a proposal was committed?
> > In a few months from now, all Groovy code samples we would come across
> > would be littered with @Typed annotations all around -- who remembers
> > the ugly @Property annotation making your Groovy beans ugly?
> > A few months later, and people will wonder why this is not the default
> > behavior and be applied to all possible methods or classes.
> > Groovy will become more and more statically typed, and for
> > "performance sake", we'd imagine other such hacks to make Groovy less
> > and less dynamic over time, or littered with ugly annotations.
>
> I'm not sure if this is really true. So far, there's plenty of Java
> programmers out there who would *love* to use Groovy if there was more
> compile time checking involved. But, and I understand that, that's not
> possible as long as everything is super-dynamic.
> It's not that I don't appreciate that, it's very very nice. Really. But
> as even a typo in a variable goes unnoticed by the compiler, it's
> annoying compared to Java to prototype an algorithm.
> So, sometimes, it would be nice to make the compiler more strict, so
> that less things go unnoticed into runtime failures.
> I can speak only for my colleagues and me, as we currently use yet
> another "alternative" language for Java development, and as syntax is
> already very similar, a switch to or coexistence with Groovy would be,
> given the possibilities of Groovy, very nice.
>
> To emphasize my point: It's less the speed (though welcome, but we are
> not doing raw numeric calculations anyway), it's the convenience and the
> confidence of getting the source through compile stage (we are not using
> an IDE) and being able to concentrate onto the algorithm itself. Maybe
> we should think about the @Typed annotation as tip to the compiler for
> stricter checks? Or we rename it and leave it to future compiler
> versions to optimize differently according to this setting?
>
> At least, we have to pick up the majority of java programmers where they
> currently are, and not where you wish them to be. I'm a strong advocate
> of Groovy and use it wherever I can and urge others to do the same. But
> given a bridge to static typed minds to get to Groovy dynamic worlds
> would help them come over...

It's not Groovy's destiny to cross that bridge. I agree with Guillaume.

Steven

>
> - --
> Patric
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: GnuPT 2.5.2
>
> iD8DBQFHutQafGgGu8y7ypARAjJcAKCyBCk38eMcpWKONXpMXjVoQySzgQCfU9D9
> i8PgPw8Us0MoIlRDnHweBPs=
> =Nxy3
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[glaforge]

On Tue, Feb 19, 2008 at 2:05 PM, Patric Bechtel
<patric.bechtel@...> wrote:

> [...]
>  I'm not sure if this is really true. So far, there's plenty of Java
>  programmers out there who would *love* to use Groovy if there was more
>  compile time checking involved. But, and I understand that, that's not
>  possible as long as everything is super-dynamic.
>  It's not that I don't appreciate that, it's very very nice. Really. But
>  as even a typo in a variable goes unnoticed by the compiler, it's
>  annoying compared to Java to prototype an algorithm.
>  So, sometimes, it would be nice to make the compiler more strict, so
>  that less things go unnoticed into runtime failures.
>  I can speak only for my colleagues and me, as we currently use yet
>  another "alternative" language for Java development, and as syntax is
>  already very similar, a switch to or coexistence with Groovy would be,
>  given the possibilities of Groovy, very nice.

Regarding more 'strictness', I think you'd be more interested in this
approach suggested by Graeme recently:
http://groovy.markmail.org/message/b65lr6u3ejkwt3kq

>  To emphasize my point: It's less the speed (though welcome, but we are
>  not doing raw numeric calculations anyway), it's the convenience and the
>  confidence of getting the source through compile stage (we are not using
>  an IDE) and being able to concentrate onto the algorithm itself. Maybe
>  we should think about the @Typed annotation as tip to the compiler for
>  stricter checks? Or we rename it and leave it to future compiler
>  versions to optimize differently according to this setting?

These kind of checks are also the job of the IDE, so that it gives you
warnings where you're doing something which is off the usual static
typing limits that Java developers are used to.
The compiler could also provide some additional checks, when certain
flags or options are activated.
Although in those cases, it's probably because you're coding Java in Groovy :-)

>  At least, we have to pick up the majority of java programmers where they
>  currently are, and not where you wish them to be. I'm a strong advocate
>  of Groovy and use it wherever I can and urge others to do the same. But
>  given a bridge to static typed minds to get to Groovy dynamic worlds
>  would help them come over...

Groovy is not just Java plus a couple of features like closures or
native syntax for lists and maps.
Groovy's goals go further than this, and if we would limit its
abilities to stay within the usual limits, we wouldn't have frameworks
like Grails, or we wouldn't be able to create Domain-Specific
Languages.
Fortunately, Groovy gives Java developers a rather flat learning
curve, and as you learn Groovy, you come to use and love more advanced
features and capabilities.

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

    http://xircles.codehaus.org/manage_email

[Tom Nichols]

I like Alex's ideas.  Yes, it does limit what Groovy can do in certain
siturations but

1. it's optional, so the developer does this of his/her own volition,
not due to any language constraints.
2.  How invasive is this change?  Is it really just a new annotation
and some hooks in the compiler?  Or does it require changes to the
runtime too?

To me this seems like just another tool.  It doesn't force Groovy in
any direction.  It just gives the developer more options.  They can
use it, or choose not to.  Yes, it would cause some things to not work
(i.e. libs that rely on runtime-dynamic stuff like GORM) but it would
allow other situations to use Groovy's great syntax and some (most?)
of its features without resorting to Java.  Why not give the developer
this tool (with the caveat that it is not a "magic speed-up button")
and allow them to use it or not?

I think that if we can suddenly have ~90% of Java's speed with such a
(seemingly) simple change, it would be well worth it.  I would
definitely prefer to write "static, annotated Groovy" versus Java.

-Tom

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

    http://xircles.codehaus.org/manage_email

[Alex Tkachman]

>
> At least, we have to pick up the majority of java programmers where they
> currently are, and not where you wish them to be. I'm a strong advocate
> of Groovy and use it wherever I can and urge others to do the same. But
> given a bridge to static typed minds to get to Groovy dynamic worlds
> would help them come over...
>
> - --
> Patric

I am 200% agreed with your words

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

    http://xircles.codehaus.org/manage_email

[glaforge]

The problem with this approach is that it'd be like focusing on the
short term and not the longer term, despite the facts that:
- it's so easy to use Java when really needed
- it wouldn't be as fast as raw Java anyway
- the code base would become littered with this annotation all over
the place for no sane reason (remember the ugly @Property all over the
place?)
- having such quick wins in place wouldn't force us to think about a
better underlying architecture, preventing Groovy from really scaling
upward any day soon

And I could certainly find other very good valid reasons.

On Tue, Feb 19, 2008 at 3:26 PM, Tom Nichols <tmnichols@...> wrote:

> I like Alex's ideas.  Yes, it does limit what Groovy can do in certain
>  siturations but
>
>  1. it's optional, so the developer does this of his/her own volition,
>  not due to any language constraints.
>  2.  How invasive is this change?  Is it really just a new annotation
>  and some hooks in the compiler?  Or does it require changes to the
>  runtime too?
>
>  To me this seems like just another tool.  It doesn't force Groovy in
>  any direction.  It just gives the developer more options.  They can
>  use it, or choose not to.  Yes, it would cause some things to not work
>  (i.e. libs that rely on runtime-dynamic stuff like GORM) but it would
>  allow other situations to use Groovy's great syntax and some (most?)
>  of its features without resorting to Java.  Why not give the developer
>  this tool (with the caveat that it is not a "magic speed-up button")
>  and allow them to use it or not?
>
>  I think that if we can suddenly have ~90% of Java's speed with such a
>  (seemingly) simple change, it would be well worth it.  I would
>  definitely prefer to write "static, annotated Groovy" versus Java.
>
>  -Tom
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

    http://xircles.codehaus.org/manage_email

[Tom Nichols]

On Feb 19, 2008 9:35 AM, Guillaume Laforge <glaforge@...> wrote:
> The problem with this approach is that it'd be like focusing on the
> short term and not the longer term, despite the facts that:
> - it's so easy to use Java when really needed

But it's easier _not_ to use Java, and breaking out pieces for
performance reasons can quickly lead to bad encapsulation and OO
design.

> - it wouldn't be as fast as raw Java anyway

Of course not just as fast, but "close enough" for the sake of such a
convenience.

> - the code base would become littered with this annotation all over
> the place for no sane reason (remember the ugly @Property all over the
> place?)

Maybe _my_ codebase.  But then that's what annotations are for.  I
don't consider it litter; it's metadata, used judiciously where
necessary.  And the current solution of "break out into Java where
needed means my codebase from a file perspective is littered with Java
files, so I have to keep switching to other files to see a complete
picture of what is going on.  I wouldn't ask such annotations to be
put in the core Groovy libs.  But let _me_ use them if I want to.
Obviously @Property wasn't necessary because a sensible convention
could be used instead. I don't think this is comparable and wouldn't
be used nearly as often.

> - having such quick wins in place wouldn't force us to think about a
> better underlying architecture, preventing Groovy from really scaling
> upward any day soon

Nobody is asking you not to make "dynamic Groovy" faster.  The two
aren't exclusive and nobody is saying "just do this and ignore the
real issue."  If it were a matter of manpower and this would take too
much effort then fine, you have to concentrate on the long term.  But
it sounds like there are other people who want to do this.

I would say this is a valid point _if_ dynamic code could become as
fast as the statically annotated equivalent.  Because then the
annotation would be obsolete.  But I think even given all of the
bytecode generation and callsite caching enhancements that have been
discussed, this annotation would still give better performance, no?
Give us both!

Thanks :)
-Tom

> On Tue, Feb 19, 2008 at 3:26 PM, Tom Nichols <tmnichols@...> wrote:
> > I like Alex's ideas.  Yes, it does limit what Groovy can do in certain
> >  siturations but
> >
> >  1. it's optional, so the developer does this of his/her own volition,
> >  not due to any language constraints.
> >  2.  How invasive is this change?  Is it really just a new annotation
> >  and some hooks in the compiler?  Or does it require changes to the
> >  runtime too?
> >
> >  To me this seems like just another tool.  It doesn't force Groovy in
> >  any direction.  It just gives the developer more options.  They can
> >  use it, or choose not to.  Yes, it would cause some things to not work
> >  (i.e. libs that rely on runtime-dynamic stuff like GORM) but it would
> >  allow other situations to use Groovy's great syntax and some (most?)
> >  of its features without resorting to Java.  Why not give the developer
> >  this tool (with the caveat that it is not a "magic speed-up button")
> >  and allow them to use it or not?
> >
> >  I think that if we can suddenly have ~90% of Java's speed with such a
> >  (seemingly) simple change, it would be well worth it.  I would
> >  definitely prefer to write "static, annotated Groovy" versus Java.
> >
> >  -Tom
> >
> >
> >
>
> >  ---------------------------------------------------------------------
> >  To unsubscribe from this list, please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> G2One, Inc. Vice-President Technology
> http://www.g2one.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[glaforge]

On Tue, Feb 19, 2008 at 4:03 PM, Tom Nichols <tmnichols@...> wrote:
> On Feb 19, 2008 9:35 AM, Guillaume Laforge <glaforge@...> wrote:
>  > The problem with this approach is that it'd be like focusing on the
>  > short term and not the longer term, despite the facts that:
>  > - it's so easy to use Java when really needed
>
>  But it's easier _not_ to use Java, and breaking out pieces for
>  performance reasons can quickly lead to bad encapsulation and OO
>  design.

Not necessarily.
And on the contrary, whether you are using inheritance or delegation,
it's very clean OO design.

>  > - it wouldn't be as fast as raw Java anyway
>
>  Of course not just as fast, but "close enough" for the sake of such a
>  convenience.

When performance really matter, and you're hitting a bottleneck in
your application, you'd better be using Java for those 50 lines of
code that need a boost, instead of just being happy with half the
performance of raw Java.

>  > - the code base would become littered with this annotation all over
>  > the place for no sane reason (remember the ugly @Property all over the
>  > place?)
>
>  Maybe _my_ codebase.  But then that's what annotations are for.  I
>  don't consider it litter; it's metadata, used judiciously where
>  necessary.  And the current solution of "break out into Java where
>  needed means my codebase from a file perspective is littered with Java
>  files, so I have to keep switching to other files to see a complete
>  picture of what is going on.

I guess it's a question of taste, and habits.
Why would we care about seamless Java integration if it was not to
integrate Groovy and Java together.
Use the right tool for the job, Groovy is not a Java replacement.

> I wouldn't ask such annotations to be
>  put in the core Groovy libs.  But let _me_ use them if I want to.
>  Obviously @Property wasn't necessary because a sensible convention
>  could be used instead. I don't think this is comparable and wouldn't
>  be used nearly as often.

It's so difficult to know for sure who's right, and what would be the
fate of this annotation.
For the record, the @Property initially looked like a nice idea, which
in the longer term seemed just stupid :-)

>  > - having such quick wins in place wouldn't force us to think about a
>  > better underlying architecture, preventing Groovy from really scaling
>  > upward any day soon
>
>  Nobody is asking you not to make "dynamic Groovy" faster.  The two
>  aren't exclusive and nobody is saying "just do this and ignore the
>  real issue."  If it were a matter of manpower and this would take too
>  much effort then fine, you have to concentrate on the long term.  But
>  it sounds like there are other people who want to do this.
>
>  I would say this is a valid point _if_ dynamic code could become as
>  fast as the statically annotated equivalent.  Because then the
>  annotation would be obsolete.  But I think even given all of the
>  bytecode generation and callsite caching enhancements that have been
>  discussed, this annotation would still give better performance, no?

Dynamic bytecode generation or call site caching are good techniques
considering the current architecture of Groovy.
But other work in the field indicates that with a carefully designed
MOP, such techniques are not necessary to gain good raw performance
comparable to Java, making other enhancements like this annotation
obsolete anyway.
Furthermore, as the work on JSR-292 (aka invokedynamic) continues, it
is highly likely that the situation will improve drastically as the
JVM is adapted to work well with dynamic languges.

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

    http://xircles.codehaus.org/manage_email

[chanwit]

Hi,

I like Alex's idea of letting compiler knows which policy could be
used for generating the code. But I agree with Guillaume that
annotations will make the code ugly. I think it would be great if we
can have something to describe the policy externally (like cascaded
style sheets), rather than putting annotations around the code.

Cheers,

Chanwit

On 19/02/2008, Guillaume Laforge <glaforge@...> wrote:

> The problem with this approach is that it'd be like focusing on the
> short term and not the longer term, despite the facts that:
> - it's so easy to use Java when really needed
> - it wouldn't be as fast as raw Java anyway
> - the code base would become littered with this annotation all over
> the place for no sane reason (remember the ugly @Property all over the
> place?)
> - having such quick wins in place wouldn't force us to think about a
> better underlying architecture, preventing Groovy from really scaling
> upward any day soon
>
> And I could certainly find other very good valid reasons.
>
> On Tue, Feb 19, 2008 at 3:26 PM, Tom Nichols <tmnichols@...> wrote:
> > I like Alex's ideas.  Yes, it does limit what Groovy can do in certain
> >  siturations but
> >
> >  1. it's optional, so the developer does this of his/her own volition,
> >  not due to any language constraints.
> >  2.  How invasive is this change?  Is it really just a new annotation
> >  and some hooks in the compiler?  Or does it require changes to the
> >  runtime too?
> >
> >  To me this seems like just another tool.  It doesn't force Groovy in
> >  any direction.  It just gives the developer more options.  They can
> >  use it, or choose not to.  Yes, it would cause some things to not work
> >  (i.e. libs that rely on runtime-dynamic stuff like GORM) but it would
> >  allow other situations to use Groovy's great syntax and some (most?)
> >  of its features without resorting to Java.  Why not give the developer
> >  this tool (with the caveat that it is not a "magic speed-up button")
> >  and allow them to use it or not?
> >
> >  I think that if we can suddenly have ~90% of Java's speed with such a
> >  (seemingly) simple change, it would be well worth it.  I would
> >  definitely prefer to write "static, annotated Groovy" versus Java.
> >
> >  -Tom
> >
> >
> >
> >  ---------------------------------------------------------------------
> >  To unsubscribe from this list, please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> G2One, Inc. Vice-President Technology
> http://www.g2one.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Guillaume Laforge wrote:
> However, as this has been discussed on this list a few times already
> or at the last Groovy Developer Conference, it's better and saner to
> make Groovy the fastest dynamic language possible on the JVM by
> creating the best second generation MOP, rather than by adding a few
> hacks to make Groovy a more statically typed language.

I agree with Guillaume. Such a change would end up making Groovy not
only less dynamic and "less Groovy", it would also make it internally
inconsistent since adding a static type declaration would change what
method a call dispatches to.

Part of the problem with introducing static typing that produces static
method binding is that much of Groovy's power comes from its ability to
override methods on a target type. Since the outward-facing static-typed
method signature does not do an additional dynamic dispatch, statically
binding to either a Groovy type's or a Java type's static method
signatures (as in Alex's experiment) would mean that additional changes
(metaprogramming et al) would not be seen by static call sites.

So ultimately, you'd have dynamic invocation for dynamic (untyped) code
and static invocation for static typed code, and mixing the two would
lead to different pieces of code calling different methods.

I'm positive Groovy can do better in the performance arena while still
remaining fully dynamic, and I have lots of ideas for how to get there
I'm willing to share and help with. But I think the value of a
dynamic-typed language is in dynamic typing...so we shouldn't optimize
for static typing, especially when it changes the invocation semantics
of the language.

- Charlie

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

    http://xircles.codehaus.org/manage_email

[Steven Devijver]

On Feb 19, 2008 5:49 PM, Charles Oliver Nutter <charles.nutter@...> wrote:

> Guillaume Laforge wrote:
> > However, as this has been discussed on this list a few times already
> > or at the last Groovy Developer Conference, it's better and saner to
> > make Groovy the fastest dynamic language possible on the JVM by
> > creating the best second generation MOP, rather than by adding a few
> > hacks to make Groovy a more statically typed language.
>
> I agree with Guillaume. Such a change would end up making Groovy not
> only less dynamic and "less Groovy", it would also make it internally
> inconsistent since adding a static type declaration would change what
> method a call dispatches to.
>
> Part of the problem with introducing static typing that produces static
> method binding is that much of Groovy's power comes from its ability to
> override methods on a target type. Since the outward-facing static-typed
> method signature does not do an additional dynamic dispatch, statically
> binding to either a Groovy type's or a Java type's static method
> signatures (as in Alex's experiment) would mean that additional changes
> (metaprogramming et al) would not be seen by static call sites.
>
> So ultimately, you'd have dynamic invocation for dynamic (untyped) code
> and static invocation for static typed code, and mixing the two would
> lead to different pieces of code calling different methods.
>
> I'm positive Groovy can do better in the performance arena while still
> remaining fully dynamic, and I have lots of ideas for how to get there
> I'm willing to share and help with. But I think the value of a
> dynamic-typed language is in dynamic typing...so we shouldn't optimize
> for static typing, especially when it changes the invocation semantics
> of the language.

Hmmm, as far as I can tell Alex's proposed changes have nothing to do
with static typing.

Steven

>
> - Charlie
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Steven Devijver wrote:

> On Feb 19, 2008 5:49 PM, Charles Oliver Nutter <charles.nutter@...> wrote:
>> Guillaume Laforge wrote:
>>> However, as this has been discussed on this list a few times already
>>> or at the last Groovy Developer Conference, it's better and saner to
>>> make Groovy the fastest dynamic language possible on the JVM by
>>> creating the best second generation MOP, rather than by adding a few
>>> hacks to make Groovy a more statically typed language.
>> I agree with Guillaume. Such a change would end up making Groovy not
>> only less dynamic and "less Groovy", it would also make it internally
>> inconsistent since adding a static type declaration would change what
>> method a call dispatches to.
>>
>> Part of the problem with introducing static typing that produces static
>> method binding is that much of Groovy's power comes from its ability to
>> override methods on a target type. Since the outward-facing static-typed
>> method signature does not do an additional dynamic dispatch, statically
>> binding to either a Groovy type's or a Java type's static method
>> signatures (as in Alex's experiment) would mean that additional changes
>> (metaprogramming et al) would not be seen by static call sites.
>>
>> So ultimately, you'd have dynamic invocation for dynamic (untyped) code
>> and static invocation for static typed code, and mixing the two would
>> lead to different pieces of code calling different methods.
>>
>> I'm positive Groovy can do better in the performance arena while still
>> remaining fully dynamic, and I have lots of ideas for how to get there
>> I'm willing to share and help with. But I think the value of a
>> dynamic-typed language is in dynamic typing...so we shouldn't optimize
>> for static typing, especially when it changes the invocation semantics
>> of the language.
>
> Hmmm, as far as I can tell Alex's proposed changes have nothing to do
> with static typing.

That's how I interpreted these statements which talk about methods that
are statically typed:

"The problem we try to solve can be formulated very simply
- we have piece of code, which is effectlvely statically typed (either
typed already or can become typed without to much problems for
developer because he knows that nothing dynamic is involved)
- we forget almost all we know about types during compilation because
we assume that everything can be dynamicly changed at any momemt"

"Someone can argue that developer can always use Java, when he needs
piece of statically typed code. There are several reasons why this is
wrong
- we seriously limit his freedom to develop
- if he needs just 1 or 2 statically typed methods, why to add another
Java class"

- Charlie

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

    http://xircles.codehaus.org/manage_email