On Thu, Feb 21, 2008 at 2:26 AM, Martin C. Martin <mar...@martincmartin.com> 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.

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.

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.

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.

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

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.

Agreede.

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

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.

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