Groovy performance: what to do

[Steven Devijver]

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

>
> 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"
>

I think Alex can is best placed to comment on this. But what I
understand is that Groovy code will be converted to byte code as is,
without going through the MOP. Hence, you should be able to do:

@Typed def count() {
    def a = 1
    def b = 1

    a + b
}

and get near-Java performance for executing the count() method (not
calling it). Again, I can be mistaken but this is what I understand
from what Alex said.

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

[Alex Tkachman]

No, you are wrong.

Your code is equalent of Java

Object count () {
  Object a = 1
  Object b = 1;
  return a + b; // compilation error
}

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

>
> On Feb 19, 2008 8:38 PM, Charles Oliver Nutter <charles.nutter@...> wrote:
> >
> > 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"
> >
>
> I think Alex can is best placed to comment on this. But what I
> understand is that Groovy code will be converted to byte code as is,
> without going through the MOP. Hence, you should be able to do:
>
> @Typed def count() {
>     def a = 1
>     def b = 1
>
>     a + b
> }
>
> and get near-Java performance for executing the count() method (not
> calling it). Again, I can be mistaken but this is what I understand
> from what Alex said.
>
> 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
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Alex Tkachman]

No, you are wrong.

Your code is equalent of Java

Object count () {
  Object a = 1
  Object b = 1;
  return a + b; // compilation error
}

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

>
> On Feb 19, 2008 8:38 PM, Charles Oliver Nutter <charles.nutter@...> wrote:
> >
> > 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"
> >
>
> I think Alex can is best placed to comment on this. But what I
> understand is that Groovy code will be converted to byte code as is,
> without going through the MOP. Hence, you should be able to do:
>
> @Typed def count() {
>     def a = 1
>     def b = 1
>
>     a + b
> }
>
> and get near-Java performance for executing the count() method (not
> calling it). Again, I can be mistaken but this is what I understand
> from what Alex said.
>
> 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
>
>
>

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

    http://xircles.codehaus.org/manage_email

[tugwilson]

Alex,

This suggestion comes up every year or so in various forms.

I'm afraid my reaction to it is always the same. It's a *really* bad idea.

Firstly it involves inventing a new language. This language has the same syntax as Groovy but completely different semantics. Actually the idea of implementing such a language is not in itself a bad idea at all. Were somebody to set up a separate project to do so I'd follow its progress with great interest. However doing it on the back of the Groovy project is, in my view, a non starter.

Secondly, the history of mixing two languages in one file has a very unhappy history. I have done a couple if implementations of languages which allow low level inserts and I never want to suffer the support issues caused by that again.

Thirdly it lets you off the hook. Groovy performance was awful and is getting better (due, to a great extent, to your good work). Once people can switch of dynamic behaviour to get higher performance the motivation for dynamic performance improvement will dramatically reduce. Groovy's performance has gone from appalling to not so good (an people have produced perfectly good production systems with Groovy's appalling performance). I'm sure you can the rest of the team can move the performance to excellent (you just have to stop trying to fix the unfixable). I am very happy to help as is Charlie (I'm reading the whole of this thread in one go as Nabble has had a Groovy burp and has held all the messages back for a day).

Fourthly you have replaced one problem (how to implement a high quality dynamic language) with two (how to implement a high quality dynamic language and how to implement a high quality static language) If you are having difficulty solving the first problem how does adding a second problem help you?

If the project were to adopt this suggestion I'm of the opinion that you would end up with a combination of a third rate dynamic language coupled with a second rate static language.

John wilson

[Alex Tkachman]

Thank you, John, for your comments! As usually it reasonable and
well-argued. Please see my thoughts below.

>
> This suggestion comes up every year or so in various forms.
>

I didn't expect that it is my invention :(

But seriously. I think all of us know the reason. It is not only
because of performance (which is very important factor) but also
because sometimes people want to have static typing and some times
don't. Right now their only option is nice Groovy syntax for dynamic
part and pure Java syntax for static. But let me repeat - THEY WANT
BOTH

> I'm afraid my reaction to it is always the same. It's a *really* bad idea.
>
> Firstly it involves inventing a new language. This language has the same
> syntax as Groovy but completely different semantics.

You are 100% correct. I had many discussions with my ex-collegues in
JetBrains, who are much better experts in languages then I, I would
say who are real experts. and they claim the same - it becomes two
languages.

And I agree with that. The question is "is it so bad"? And my answer
is "no, as long as we and users understand what and why is going on"
Vice versa, I believe there is demand and such approach will fulfill
the demand.

> Actually the idea of
> implementing such a language is not in itself a bad idea at all. Were
> somebody to set up a separate project to do so I'd follow its progress with
> great interest. However doing it on the back of the Groovy project is, in my
> view, a non starter.
>
> Secondly, the history of mixing two languages in one file has a very unhappy
> history. I have done a couple if implementations of languages which allow
> low level inserts and I never want to suffer the support issues caused by
> that again.
>
> Thirdly it lets you off the hook. Groovy performance was awful and is
> getting better (due, to a great extent, to your good work). Once people can
> switch of dynamic behaviour to get higher performance the motivation for
> dynamic performance improvement will dramatically reduce. Groovy's
> performance has gone from appalling to not so good (an people have produced
> perfectly good production systems with Groovy's appalling performance).

You said very right words "stop trying to fix unfixable". But look, do
we have real choice? A lot of people use Groovy already and, what is
much more important, A LOT of people start to use both Groovy and
Grails on their new development or integrate it in to their existing
products right now. Should we say to them "hey guys, go forward, but
it might happen that in 6-9 months we will give you Groovy 2.0 with
new MOP etc., which potentially will be huge breaking change"? I am
not sure.

<IMPORTANT NOTE FOR GROOVY USERS>
There is no any direct or indirect agreed plans to make serious
breaking changes in Groovy language or runtime. As always nobody want
to create troubles for users just for fun or to simplify life of
developers of Groovy Core.
</IMPORTANT NOTE FOR GROOVY USERS>

I believe that there are huge chances that breaking changes will not
be huge. The problem is I would feel myself much more comfortable if
we had design for so-called MOP 2.0 (I completely agree what existing
MOP is suboptimal both in design and implementation), which fulfill
just 2 but conflicting requirements
- maximal compatibility with existing code
- much better performance

Hey, join the team back, show your vision of design and let us
implement it if it is great :)

> I'm sure you can the rest of the team can move the performance to excellent (you
> just have to stop trying to fix the unfixable). I am very happy to help as
> is Charlie (I'm reading the whole of this thread in one go as Nabble has had
> a Groovy burp and has held all the messages back for a day).
>

Seriously, yours and Charlie's help is really valuable. It is great
source of ideas and experience. At least for me. I don't know the
story why you are not involved directly to Groovy development any more
but I am really sorry for that. I am sure not only me will be happy if
you decided to participate again not only by ideas and expirience but
by real development as well. Anyway, thank you once more for all your
help.

> Fourthly you have replaced one problem (how to implement a high quality
> dynamic language) with two (how to implement a high quality dynamic language
> and how to implement a high quality static language) If you are having
> difficulty solving the first problem how does adding a second problem help
> you?
>

As I said I believe there is huge user demand for mixed typing. So I
don't add new problem but reformulate existing one.

> If the project were to adopt this suggestion I'm of the opinion that you
> would end up with a combination of a third rate dynamic language coupled
> with a second rate static language.
>

Here I don't agree with you. I believe that we have good chances for
high class language with mixed typing.

> John wilson
>

Alex

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

    http://xircles.codehaus.org/manage_email

[glaforge]

On Feb 20, 2008 5:51 AM, Alex Tkachman <alex.tkachman@...> wrote:
> [...]
> But seriously. I think all of us know the reason. It is not only
> because of performance (which is very important factor) but also
> because sometimes people want to have static typing and some times
> don't. Right now their only option is nice Groovy syntax for dynamic
> part and pure Java syntax for static. But let me repeat - THEY WANT
> BOTH

People also want free food from top chiefs, affordable top model
dresses from "haute couture" dressmakers, but it's not necessarily
possible :-)

> [...]
> You are 100% correct. I had many discussions with my ex-collegues in
> JetBrains, who are much better experts in languages then I, I would
> say who are real experts. and they claim the same - it becomes two
> languages.
>
> And I agree with that. The question is "is it so bad"? And my answer
> is "no, as long as we and users understand what and why is going on"
> Vice versa, I believe there is demand and such approach will fulfill
> the demand.

Statically typed language experts will undoubtedly demand for such an
approach. It's difficult to make the mental switch.
I recently talked with a dynamic language expert whom I highly respect
(and who's got a strong smalltalk background) agreed with me that this
approach would bloat the language into two, for no sane reason -- and
I won't list again and again all the good reasons why it's not such a
good idea as I've already done it several times.

> [...]
> > Secondly, the history of mixing two languages in one file has a very unhappy
> > history. I have done a couple if implementations of languages which allow
> > low level inserts and I never want to suffer the support issues caused by
> > that again.

I feel your pain.
One area which will become even more painful will be with support, to
properly understand what's going on at the boundaries where both
worlds meet.

> > Thirdly it lets you off the hook. Groovy performance was awful and is
> > getting better (due, to a great extent, to your good work). Once people can
> > switch of dynamic behaviour to get higher performance the motivation for
> > dynamic performance improvement will dramatically reduce.

Agreed, and in the end, there's no added value to Groovy itself --
over 4 years of R&D for nothing.

> > Groovy's
> > performance has gone from appalling to not so good (an people have produced
> > perfectly good production systems with Groovy's appalling performance).
>
> You said very right words "stop trying to fix unfixable". But look, do
> we have real choice? A lot of people use Groovy already and, what is
> much more important, A LOT of people start to use both Groovy and
> Grails on their new development or integrate it in to their existing
> products right now. Should we say to them "hey guys, go forward, but
> it might happen that in 6-9 months we will give you Groovy 2.0 with
> new MOP etc., which potentially will be huge breaking change"? I am
> not sure.

It is not necessarily a 'huge' breaking change.
Trying to make Groovy users afraid of the future is a bad trick, and a
sure way to loose users and damage the future of Groovy itself.
That's a classical FUD technique to assert your ideas and claims.

> <IMPORTANT NOTE FOR GROOVY USERS>
> There is no any direct or indirect agreed plans to make serious
> breaking changes in Groovy language or runtime. As always nobody want
> to create troubles for users just for fun or to simplify life of
> developers of Groovy Core.
> </IMPORTANT NOTE FOR GROOVY USERS>

At least that's a good thing you reckon it :-)

> I believe that there are huge chances that breaking changes will not
> be huge. The problem is I would feel myself much more comfortable if
> we had design for so-called MOP 2.0 (I completely agree what existing
> MOP is suboptimal both in design and implementation), which fulfill
> just 2 but conflicting requirements
> - maximal compatibility with existing code
> - much better performance

These goals are just great and are not necessarily conflicting, as a
rework of the architecture will certainly bring much better
performance, and it should also be designed such as it remains
faithful to the core value of Groovy which is seamless integration
with Java.

> [...]
> > Fourthly you have replaced one problem (how to implement a high quality
> > dynamic language) with two (how to implement a high quality dynamic language
> > and how to implement a high quality static language) If you are having
> > difficulty solving the first problem how does adding a second problem help
> > you?

Agreed.

> [...]
> As I said I believe there is huge user demand for mixed typing. So I
> don't add new problem but reformulate existing one.

There is a higher demand for a top-notch Eclipse IDE support.
And there's a good demand for higher performance (who wouldn't want it
anyway?), but the answer is not necessarily mixed typing.

> [...]
> > If the project were to adopt this suggestion I'm of the opinion that you
> > would end up with a combination of a third rate dynamic language coupled
> > with a second rate static language.

Yes, in the end, it would be very bad for the future of Groovy and its adoption.


--
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

[Jochen Theodorou]

Alex Tkachman schrieb:

> No, you are wrong.
>
> Your code is equalent of Java
>
> Object count () {
>   Object a = 1
>   Object b = 1;
>   return a + b; // compilation error
> }
>

we could let the compiler infere the tpye if def is used. then you ave
still a static type, but you can do "def a=1; def b=1; a+b"

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

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

    http://xircles.codehaus.org/manage_email

[Martin C. Martin]

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.
>
> 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?

True, although it could be changed to a keyword.  "static" is already
taken in Java (and C and C++) to mean something else, but we could think
of another keyword, e.g. "typed."

> 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 surprised you're so sure how people would use this particular
feature.  I work with the one language I know of that has optional
typing for efficiency: Lisp.  In our code base, it's not used too much,
because (a) most people worry about getting the job done, and only focus
on performance when it becomes a problem, and (b) it tends to clutter up
the code, and people don't want to clutter up the code for no good
reason.  It seems a strong possibility that this would turns out the
same way in Groovy.  However, it's also possible things will turn out
the way you say.

But, I'm not sure it's such a bad thing.  People tend to assume things
are static, and are surprised by the (possibility of) the dynamic
nature.  For example, people are often surprised that mylist.size()
can't be compiled to mylist.length.  They're even more surprised that
when used in a loop, that it isn't resolved just the first time through
but every time through.

> 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.

I'm worried that this will end up turning into a Sufficiently Smart
Compiler, something that's so hard to do right that it never happens:

http://c2.com/cgi/wiki?SufficientlySmartCompiler

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

True, but it would often be "fast enough."  If Groovy is, say, 10 to 20
times slower than Java, and by sprinkling a few keywords or annotations
around you can get it 2 times slower, that will often be good enough,
and there'll be no reason to rewrite it in Java.

> 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.

Actually, that's not true.  The main product of the company I work for
is a search engine for air fares.  It's used by some of the main travel
sites in the U.S. (Orbitz.com and Kayak.com), and by most big U.S.
airlines.  It's very performance intensive code; whenever you do a
search, it takes many seconds to find the answer, and that's one of the
biggest complaints.  Yet it's not written in C/C++ or any other
statically typed language.  It's written in Lisp.

Why?  Because its complex algorithmic code, and it would be several
times longer in a statically typed language.  It would be even harder to
understand.  There's no single bottleneck, there are around 20 stages,
and depending on the query each of them can take a significant amount of
time.

So, I think it's a shame that Groovy can't replace Java, and I really
don't see why it couldn't.

> 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.

Faster than Ruby and Python is realistic without compiler hints, but it
seems that significantly faster than that is relatively easy to do.

I wonder: how often are the more extreme dynamic aspects of Groovy, or
any dynamic language, actually used?  How often is a meta object
protocol (other than default ones) actually used?  How often are
per-instance MOPs used?  How often are the changed at runtime?

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

    http://xircles.codehaus.org/manage_email

[glaforge]

On Thu, Feb 21, 2008 at 2:26 AM, Martin C. Martin
<martin@...> wrote:
> [...]
>  True, although it could be changed to a keyword.  "static" is already
>  taken in Java (and C and C++) to mean something else, but we could think
>  of another keyword, e.g. "typed."

It's not a problem of annotation vs keyword.
It's the concept which is not the right thing to do.
It's about making the whole Groovy language faster in all possible
scenarios, not just through one hack to speed-up one or two methods,
which will never be as fast as Java anyway.
Let's make everything at least as fast as this hack.

>  [...]
>
>  > 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 surprised you're so sure how people would use this particular
>  feature.  I work with the one language I know of that has optional
>  typing for efficiency: Lisp.  In our code base, it's not used too much,
>  because (a) most people worry about getting the job done, and only focus
>  on performance when it becomes a problem, and (b) it tends to clutter up
>  the code, and people don't want to clutter up the code for no good
>  reason.  It seems a strong possibility that this would turns out the
>  same way in Groovy.  However, it's also possible things will turn out
>  the way you say.

Nobody can forsee what tomorrow will be like, of course :-)
My goal here is really to make Groovy as elegant as possible, free of hacks.
In the life of the projects, Groovy's evolved by layering "good ideas
of the day" over another.
The result is still okay as it is today, but however good this
pragmatic approach is, we have to be careful more and more about the
overal elegance, homogeneity and adequacy of the language, its
features, and its APIs.
If we don't reflect more on elegance, people will start soon to say
that Groovy is bloated, and will shy away from it, just as they
already do with Java itself.

>  But, I'm not sure it's such a bad thing.  People tend to assume things
>  are static, and are surprised by the (possibility of) the dynamic
>  nature.  For example, people are often surprised that mylist.size()
>  can't be compiled to mylist.length.  They're even more surprised that
>  when used in a loop, that it isn't resolved just the first time through
>  but every time through.

This may be true to newcomers.
People choose and love Groovy not because it's just like Java, but
because of all the possibilities it opens.
Otherwise, there's no real good reason to use Groovy if not to benefit
from its power-features, thanks to its dynamicity.

>  [...]
>  > 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.
>
>  I'm worried that this will end up turning into a Sufficiently Smart
>  Compiler, something that's so hard to do right that it never happens:
>
>  http://c2.com/cgi/wiki?SufficientlySmartCompiler

First of all, it's not about the compiler, but about the runtime system.
So it's really two different things.
Secondly, work being done by Charles Nutter or John Wilson prove that
it's possible to achieve high performance, less than an order of
magnitude from Java, so we know it's achievable and doable.
In that case, everything would be as fast as this ugly hack which
disfigures the beauty of the language by mixing different typing
concepts.

>  [...]
>  > Furthermore, even with such an annotation, this code path would always
>  > be slower than raw Java anyway.
>
>  True, but it would often be "fast enough."  If Groovy is, say, 10 to 20
>  times slower than Java, and by sprinkling a few keywords or annotations
>  around you can get it 2 times slower, that will often be good enough,
>  and there'll be no reason to rewrite it in Java.

Again, the goal is really to have everything "fast enough", not just
one corner case.
It's an ambitious goal, but it's achievable.

>  [...]
>  > When raw performance matter, using Java is simply the best option, and
>  > nothing we could do would make the code faster than raw Java.
>
>  Actually, that's not true.  The main product of the company I work for
>  is a search engine for air fares.  It's used by some of the main travel
>  sites in the U.S. (Orbitz.com and Kayak.com), and by most big U.S.
>  airlines.  It's very performance intensive code; whenever you do a
>  search, it takes many seconds to find the answer, and that's one of the
>  biggest complaints.  Yet it's not written in C/C++ or any other
>  statically typed language.  It's written in Lisp.

Fine, and you know, lots of companies already use Groovy in
mission-critical applications, and they just cope very well, even with
older versions of Groovy which were far from what Groovy is today!
As long as your SLAs are met, then that's fine if everything's in
Groovy, even if some parts could be made snappier, but if it's at the
cost of less readability, and more maintenance headache, it wouldn't
probably worth it anyway.

>  Why?  Because its complex algorithmic code, and it would be several
>  times longer in a statically typed language.  It would be even harder to
>  understand.  There's no single bottleneck, there are around 20 stages,
>  and depending on the query each of them can take a significant amount of
>  time.

Agreede.

>  So, I think it's a shame that Groovy can't replace Java, and I really
>  don't see why it couldn't.

It's a bit taken out of context to just say that.
I've never said Groovy can't replace Java.
And I'd be happy if it would replace it, after all.
What I'm saying is that it's never been a goal per se to replace Java.
Groovy's always been thought as a complement, to simplify the life of
developers, to play nice with the Java ecosystem.
If it had not been the case, then we would have not cared that much
about seamless integration, and so on, and we would have designed a
brand new language from scratch, without copying the ugliness of Java
(the old for loop being the most basic example of an old disgraceful C
heritage).

>  [...]
>  Faster than Ruby and Python is realistic without compiler hints, but it
>  seems that significantly faster than that is relatively easy to do.

I sincerely believe that we can beat these languages, especially as
the JVM evolves to support dynamic languages better, and with careful
attention to the new architecture of Groovy.

>  I wonder: how often are the more extreme dynamic aspects of Groovy, or
>  any dynamic language, actually used?  How often is a meta object
>  protocol (other than default ones) actually used?  How often are
>  per-instance MOPs used?  How often are the changed at runtime?

In Grails, all the time! in all possible places! From top to bottom,
and vice versa!

In Groovy itself, it highly depends on your usage of Groovy.
If you're using Groovy just for some scripting / admin tasks, then you
most propably don't care too much anyway, and in general, performance
is not even a real concern.
If you're using Groovy for your testing / mocking needs, all the
niceties offered by Groovy's Mock support or by frameworks like Easyb,
etc, then you highly depend on the dynamic aspects of Groovy.
If you're using Groovy to extend existing Java application, to offer
extension points, it'll depend on how you integrate it, and how
friendly this integration gotta be. It could be made even better by
leveraging metaclasses at key places.
And if you're using Groovy as a business language, through DSL
techniques, then again, you'll highly depend on the MOP.

The dynamicity of Groovy is what makes Groovy shine, what makes Groovy
popular, what makes Groovy attractive, what makes it powerful.

--
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 Thu, Feb 21, 2008 at 4:35 AM, Guillaume Laforge <glaforge@...> wrote:
>  It's not a problem of annotation vs keyword.
>  It's the concept which is not the right thing to do.
>  It's about making the whole Groovy language faster in all possible
>  scenarios, not just through one hack to speed-up one or two methods,
>  which will never be as fast as Java anyway.
>  Let's make everything at least as fast as this hack.

I think the "pro static annotation" people are basing their argument
on the assumption that "pure" dynamic Groovy will never be able to
attain the same performance of a non-dynamic-annotated variant.  If
re-architecting Groovy's MOP will allow it to attain ~half of Java's
speed, then fine, that's great, go there.

But I agree with Martin's argument that most people will ignore such
an annotation until it comes time to do performance tuning anyway.
Then sprinkle a few annotations in the performance bottlenecks, versus
(the current solution) breaking some code out into Java classes.  Like
I said, I would prefer the former, but if it truly won't be necessary
after "Groovy 2.0" then it is a moot point.

As annotations go, aren't they modular in the sense that you can add
hooks into places without them actually being hard-coded into the
compiler?  Maybe the groovy compiler doesn't support it now, but
doesn't the Java (5 or 6) compiler?  Would it be possible to allow
this compile-time annotation without "invading" core Groovy?

-Tom

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

    http://xircles.codehaus.org/manage_email

[Martin C. Martin]

The people steering Groovy are firmly against the idea of programmers
providing hints to the runtime that the semantics of some class or
object are simple.  I can appreciate their position.  I'm a firm
believer that languages should be driven by a single vision, held by a
single person or a small group of like minded people, and one of the
things that makes Groovy my favourite language is its wonderful design
and semantics.

An advantage of open source is to allow sub groups to experiment with
alternatives.  Alex, how hard would it be to provide a patch to support
this extension?  Then, people who want to experiment with this
FastGroovy, or whatever you want to call it, could do so.

There are a couple options I see:

1. An annotation or keyword which changes the semantics of Groovy, the
way you've proposed.

2. A kind of hint to the compiler that variable X contains an object of
class Y or one of its subclasses, and that it uses some metaclass known
at compile time.  At runtime, you can check to see whether that's true,
and if so, call the appropriate method.  If not, fall back on the
traditional call dispatch.

3. Like 2, but it's an assertion.  If the hint isn't true, signal an
error.  Perhaps have some way to even skip the check in very performance
critical code, so that it just calls the appropriate method.  Maybe this
reduces to 1. in that case, although I'm not familiar with the details
enough.

I really think this is a philosophical difference in the goal of the
language, and best settled by experimentation.  The experiment would
help answer the question "how much would we have to change Groovy to
have the best of both worlds: extreme dynamism most of the time, yet
performance within 2x Java's when needed.  How often would this work
easily, predictably, and intuitively, vs. how often would it lead to
messy interactions."

I really feel that we could be on the cusp of having both flexibility
and performance, by simply making it easier to specify simple semantics
when that's what you want anyway.  I think it could be quite exciting to
explore when and where this is possible, when we could retool libraries
that use a lot of dynamics to use less (without reducing features), etc.

What do people think?

Best,
Martin

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

[Tom Nichols]

On Thu, Feb 21, 2008 at 8:45 AM, Martin C. Martin
<martin@...> wrote:
> when we could retool libraries
>  that use a lot of dynamics to use less (without reducing features), etc.

I wouldn't even go there.  Don't change any core libraries.  Don't
change anything except add an annotation (*not a keyword*) and a
compiler hook (whatever way is least invasive).  I personally am not
looking for changes to the language per se.  More like just how the
bytecode is generated when the code is compiled.

There are TONS of places where any sort of "not-dynamic" semantics
would mean certain core libs, and most of Grails wouldn't work inside
such an annotated method i.e. map.someValue (right?) builders,
slurpers, categories, obj."$method", etc.  But this leaves a whole
category of code that (as Martin said) is very straightforward and
involves just direct method calls, arithmetic, etc.  I would *love* to
be able to choose "non-dynamic" Groovy syntax for my performant pieces
of code rather than using Java classes.  Question -- would GDK methods
(like myList.each {.. } ) still work?  Are they resolved into direct
bytecode or do they go through the MOP?

-Tom

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

    http://xircles.codehaus.org/manage_email

[Smith, Jason, CTR, OASD(HA)/TMA]

Um, maybe we could end this whole debate by making the GroovyClassloader
compile *.java files on the fly, the way it works with *.groovy files?
That way, we could treat Java like script.  No compile step.  

It would be pretty trivial to do this, I think.

This whole line of thought (performance through language extensions) is
starting to bug me.  I don't want to see Groovy turn into Java, or
replace Java.  This is starting to remind me of some of the wrong turns
taken in the transition from C to C++, and I hope this idea doesn't get
legs.


Jason Smith
 

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

    http://xircles.codehaus.org/manage_email

[Martin C. Martin]

Tom Nichols wrote:
> On Thu, Feb 21, 2008 at 8:45 AM, Martin C. Martin
> <martin@...> wrote:
>> when we could retool libraries
>>  that use a lot of dynamics to use less (without reducing features), etc.
>
> I wouldn't even go there.  Don't change any core libraries.

Well, I'm not talking about changing anything in Groovy distribution at
all.  Not even adding an annotation or a keyword.  Guillaume and others
have been very clear about that, and I respect that.  So don't install a
3rd party patch, it won't affect you.

But I think it's an important question to ask: where can we reduce
dynamism and still get all the features we know and love?  Is there some
other way to write the code that's about as clean, has the same
features, but is a lot faster?

Do you think it's worth trying that, at least as an experiment to help
drive the evolution of a FastGroovy?

>  Don't
> change anything except add an annotation (*not a keyword*) and a
> compiler hook (whatever way is least invasive).  I personally am not
> looking for changes to the language per se.  More like just how the
> bytecode is generated when the code is compiled.
>
> There are TONS of places where any sort of "not-dynamic" semantics
> would mean certain core libs, and most of Grails wouldn't work inside
> such an annotated method i.e. map.someValue (right?) builders,
> slurpers, categories, obj."$method", etc.  But this leaves a whole
> category of code that (as Martin said) is very straightforward and
> involves just direct method calls, arithmetic, etc.  I would *love* to
> be able to choose "non-dynamic" Groovy syntax for my performant pieces
> of code rather than using Java classes.  Question -- would GDK methods
> (like myList.each {.. } ) still work?  Are they resolved into direct
> bytecode or do they go through the MOP?

Going through the MOP doesn't need to be a deal breaker, as long as you
can interrogate the MOP at compile time and, in common cases, find out
what will be called.  After all, you, me and the IDEs know (or guess)
what myList.each { ... } calls.  We rely on that understanding when
we're writing code, and if it resolved to something else, we could be
quite confused.  (There are many valid cases where it could resolve to
something else, e.g. a "profiling MOP" that intercepts the method call
to increment a counter before doing the call, or for mocking during
testing, etc.)

Best,
Martin

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

    http://xircles.codehaus.org/manage_email

[glaforge]

On Thu, Feb 21, 2008 at 3:34 PM, Smith, Jason, CTR, OASD(HA)/TMA
<Jason.Smith.ctr@...> wrote:
> Um, maybe we could end this whole debate by making the GroovyClassloader
>  compile *.java files on the fly, the way it works with *.groovy files?
>  That way, we could treat Java like script.  No compile step.
>
>  It would be pretty trivial to do this, I think.

The joint Groovy / Java compiler just does it in Groovy 1.5.
Seamlessly mixing both languages is a real no-brainer.

>  This whole line of thought (performance through language extensions) is
>  starting to bug me.  I don't want to see Groovy turn into Java, or
>  replace Java.  This is starting to remind me of some of the wrong turns
>  taken in the transition from C to C++, and I hope this idea doesn't get
>  legs.

I can't agree more :-)
I really don't want to see Groovy's philosophy and goals be perverted that way.

--
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 Thu, Feb 21, 2008 at 3:44 PM, Martin C. Martin
<martin@...> wrote:

> [...]
>  Well, I'm not talking about changing anything in Groovy distribution at
>  all.  Not even adding an annotation or a keyword.  Guillaume and others
>  have been very clear about that, and I respect that.  So don't install a
>  3rd party patch, it won't affect you.
>
>  But I think it's an important question to ask: where can we reduce
>  dynamism and still get all the features we know and love?  Is there some
>  other way to write the code that's about as clean, has the same
>  features, but is a lot faster?
>
>  Do you think it's worth trying that, at least as an experiment to help
>  drive the evolution of a FastGroovy?

FastGroovy isn't Groovy anymore.
It's a fork, it's another language.

> [...]
>  Going through the MOP doesn't need to be a deal breaker, as long as you
>  can interrogate the MOP at compile time and, in common cases, find out
>  what will be called.  After all, you, me and the IDEs know (or guess)
>  what myList.each { ... } calls.  We rely on that understanding when
>  we're writing code, and if it resolved to something else, we could be
>  quite confused.  (There are many valid cases where it could resolve to
>  something else, e.g. a "profiling MOP" that intercepts the method call
>  to increment a counter before doing the call, or for mocking during
>  testing, etc.)

That's here you're failing to see what a MOP is, and forget about its
dynamic nature.
At runtime, anyone is able (if he so desires and it'll still be valid
Groovy) to change anything, even the semantics of 1+1, of myList.each
{}, etc.
We can't make assumptions that no such runtime changes in behaviour
are happening, and the compiler would in the end generate invalid code
which would break all the goodness added by a framework supporting
dynamic features and runtime modifications.

Let me state it again: Groovy is a dynamic language.

Going against this would be betraying the core values and philosophy
of the language.

--
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

[Smith, Jason, CTR, OASD(HA)/TMA]

The joint Groovy / Java compiler does, but you still need a compile
step.  And I use that feature (groovyc), and love it dearly!  

I am talking about runtime compilation of Java.  It is sort of out of
the domain of Groovy to do so (not the polite thing to do), since you'd
be "interpreting" Java on the fly, the same way Groovy is "interpreted"
on the fly.  Java has built in support for doing this sort of thing, but
I think it only works with the SDK, not the JDK.

Anyhow, you can freely mix .groovy and .java using GroovyC (1.5.x).  Why
not allow mixing them freely from uncompiled script files as well?  That
way, if you are working with groovy as a scripting language, you can
just put your speed critical code into a Java class, in the same
package, and there is no need to add a compile step for the Java
portion.

It is also kind of a cool way for a beginner to run Java.  You could
even add support to run *.java files from the command line, the way we
run *.groovy files now.

Well, it may not be a GOOD idea, but it is an idea nonetheless.  And I
think it would be easy to do.


Jason Smith
 
-----Original Message-----
From: Guillaume Laforge [mailto:glaforge@...]
Sent: Thursday, February 21, 2008 7:48 AM
To: dev@...
Subject: Re: [groovy-dev] Groovy performance: what to do

On Thu, Feb 21, 2008 at 3:34 PM, Smith, Jason, CTR, OASD(HA)/TMA
<Jason.Smith.ctr@...> wrote:
> Um, maybe we could end this whole debate by making the
> GroovyClassloader  compile *.java files on the fly, the way it works
with *.groovy files?
>  That way, we could treat Java like script.  No compile step.
>
>  It would be pretty trivial to do this, I think.

The joint Groovy / Java compiler just does it in Groovy 1.5.
Seamlessly mixing both languages is a real no-brainer.


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

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Tom Nichols wrote:
> I think the "pro static annotation" people are basing their argument
> on the assumption that "pure" dynamic Groovy will never be able to
> attain the same performance of a non-dynamic-annotated variant.  If
> re-architecting Groovy's MOP will allow it to attain ~half of Java's
> speed, then fine, that's great, go there.

I believe that, excluding raw numeric performance for which primitives
are necessary, Groovy and other JVM dynlangs can approach Java speed
with appropriate designs. We just need a bit more work to get there.

- Charlie

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

    http://xircles.codehaus.org/manage_email

[glaforge]

Oh right, sorry, I misunderstood your idea and immediately thought
about the joint compiler.
Well, actually, this would certainly be feasable.
The Java compiler API should allow you to do that pretty easily anyway, yes.


On Thu, Feb 21, 2008 at 4:19 PM, Smith, Jason, CTR, OASD(HA)/TMA
<Jason.Smith.ctr@...> wrote:

> The joint Groovy / Java compiler does, but you still need a compile
>  step.  And I use that feature (groovyc), and love it dearly!
>
>  I am talking about runtime compilation of Java.  It is sort of out of
>  the domain of Groovy to do so (not the polite thing to do), since you'd
>  be "interpreting" Java on the fly, the same way Groovy is "interpreted"
>  on the fly.  Java has built in support for doing this sort of thing, but
>  I think it only works with the SDK, not the JDK.
>
>  Anyhow, you can freely mix .groovy and .java using GroovyC (1.5.x).  Why
>  not allow mixing them freely from uncompiled script files as well?  That
>  way, if you are working with groovy as a scripting language, you can
>  just put your speed critical code into a Java class, in the same
>  package, and there is no need to add a compile step for the Java
>  portion.
>
>  It is also kind of a cool way for a beginner to run Java.  You could
>  even add support to run *.java files from the command line, the way we
>  run *.groovy files now.
>
>  Well, it may not be a GOOD idea, but it is an idea nonetheless.  And I
>  think it would be easy to do.
>
>
>  Jason Smith
>
>
>  -----Original Message-----
>  From: Guillaume Laforge [mailto:glaforge@...]
>  Sent: Thursday, February 21, 2008 7:48 AM
>  To: dev@...
>  Subject: Re: [groovy-dev] Groovy performance: what to do
>
>  On Thu, Feb 21, 2008 at 3:34 PM, Smith, Jason, CTR, OASD(HA)/TMA
>  <Jason.Smith.ctr@...> wrote:
>  > Um, maybe we could end this whole debate by making the
>  > GroovyClassloader  compile *.java files on the fly, the way it works
>  with *.groovy files?
>  >  That way, we could treat Java like script.  No compile step.
>  >
>  >  It would be pretty trivial to do this, I think.
>
>  The joint Groovy / Java compiler just does it in Groovy 1.5.
>  Seamlessly mixing both languages is a real no-brainer.
>
>
>
>
> ---------------------------------------------------------------------
>  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

[Martin C. Martin]

Guillaume Laforge wrote:

> On Thu, Feb 21, 2008 at 3:44 PM, Martin C. Martin
> <martin@...> wrote:
>> [...]
>>  Well, I'm not talking about changing anything in Groovy distribution at
>>  all.  Not even adding an annotation or a keyword.  Guillaume and others
>>  have been very clear about that, and I respect that.  So don't install a
>>  3rd party patch, it won't affect you.
>>
>>  But I think it's an important question to ask: where can we reduce
>>  dynamism and still get all the features we know and love?  Is there some
>>  other way to write the code that's about as clean, has the same
>>  features, but is a lot faster?
>>
>>  Do you think it's worth trying that, at least as an experiment to help
>>  drive the evolution of a FastGroovy?
>
> FastGroovy isn't Groovy anymore.
> It's a fork, it's another language.

There are many, including the core Groovy team, who see it as another
language.  There are many others who see it as a small extension with
limited impact.

>> [...]
>>  Going through the MOP doesn't need to be a deal breaker, as long as you
>>  can interrogate the MOP at compile time and, in common cases, find out
>>  what will be called.  After all, you, me and the IDEs know (or guess)
>>  what myList.each { ... } calls.  We rely on that understanding when
>>  we're writing code, and if it resolved to something else, we could be
>>  quite confused.  (There are many valid cases where it could resolve to
>>  something else, e.g. a "profiling MOP" that intercepts the method call
>>  to increment a counter before doing the call, or for mocking during
>>  testing, etc.)
>
> That's here you're failing to see what a MOP is, and forget about its
> dynamic nature.
> At runtime, anyone is able (if he so desires and it'll still be valid
> Groovy) to change anything, even the semantics of 1+1, of myList.each
> {}, etc.
> We can't make assumptions that no such runtime changes in behaviour
> are happening, and the compiler would in the end generate invalid code
> which would break all the goodness added by a framework supporting
> dynamic features and runtime modifications.
>
> Let me state it again: Groovy is a dynamic language.
>
> Going against this would be betraying the core values and philosophy
> of the language.

You're right, this extension would change a basic tenant of Groovy as it
is today.  In circumstances controlled by the programmer, they could
take away the ability of anyone to change the semantics of certain
objects or pieces of code.  The idea is that they'd use this in cases
where they don't want those kinds of dynamic behaviour anyway.  After
all, you lose that (and a tonne of other stuff!) when you rewrite in
Java.  So there are certainly times when you don't miss it.

I see this as an interesting extension, the ability to turn something
off when you don't need it.  I don't really understand your use of the
emotional term "betraying."  Is it really so important to have the
ability to do dynamic things always, even when you don't want to do
them?  To me, it wouldn't be a fundamental change to Groovy to be able
to tell the compiler "Thanks for all those nifty features, but in this
one situation, I'm not using that one particular feature."  I have a
hard time understanding your argument as more than "being as dynamic as
possible is always good no matter what."  You've brought up some valid
points, such as overuse of the feature leading to ugly (and therefore
harder to read, understand and maintain) code.  I think doing some
experiments would help understand how this would be used and abused.
That's really all I'm saying.

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

    http://xircles.codehaus.org/manage_email