Tentative Roadmap

[glaforge]

On Dec 17, 2007 8:42 PM, Warner Onstine <warnero@...> wrote:

> On Dec 16, 2007 6:25 PM, Andres Almiray <aalmiray@...> wrote:
> >
> > Looks great, specially the incremental compiler as we would definitely use it
> > at work too.
> > I wonder where does handling private access fall? as well as possibly
> > allowing < <= => > to be overridden independently of <=>
>
> +1 on this. Honestly this one little omission really hamstrings Groovy
> in certain respects and I would love to see method
> overloading/overriding become complete (I have at least one bug on
> this and have voted for another).

If you can make sure that these bugs you mention are scheduled for
1.6, that would be very helpful.

> Other than that I think the roadmap looks good.

Thanks :-)

--
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 developers list is open to anyone, but it usually contains more technical information than most users care to see.  the logical progression is that something like a "Roadmap" would go through discussions on the developer's side, based on what they believe the user requirements are (remember, there is a very extensive Jira archive to pull from).  Then there might be some discussion on the user's list, or it might just go out to a wiki and get mentioned on the user's list.  

And you can be sure, if there is opposition on the user's list, or if something got missed, it is taken into account and prioritized appropriately given size and perceived importance. The development cycles for Groovy are very flexible and very fluid.  Once you get familiar with how the project is run, you'll realize it is about as open and public as projects come.

This ISN'T like Microsoft, where the roadmap will be known internally years before it becomes public.  All emails on the dev group are posted publicly on the web, and are highly searchable through Google.  And anyone can subscribe and post to the dev group.  You dig?

Stay groovy.


Jason Smith

On Dec 17, 2007 8:30 PM, Jörg Staudemeyer <jstaudemeyer@...> wrote:
> Hi Guillaume ...
>
> 2007/12/17, Guillaume Laforge <glaforge@...>:
> > Dear Groovy developers,
>
> why do you address Groovy developers only? Looks a bit as if you make
> Groovy for yourselves and not for users.


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

    http://xircles.codehaus.org/manage_email

[Scott Hickey-3]

The ability to provide the 1.5.x series of release with bug fixes and minimal changes is important. We need to be able to release these without adding any experimental code to these releases.

The thing I really like about the spirit of Guillaume's roadmap is that it outlines a path for more frequent releases. On my big Groovy project, we've been running on 1-1-beta-2 since early last summer.  It's my impression that a lot of new functionality was added since then. We really wanted some of the the improvements and fixes that already existed at that time and wanted to put something into production that wasn't "beta". This long release cycle with so much new functionality in one release made upgrading to Groovy 1.5 (nearly six months later) more expensive than at any time since I've started using Groovy with the original JSR release. I had to regression test our app for beta-3, RC-1, RC-2, RC-3.  With each RC, something new changed that worked fine in beta-2/beta-3. In an ideal world (specifically for me and this project), it would have been great to create a release with less new functionality in the middle of the summer.

People in the community will continue to develop and contribute small (relative to changing the MOP) fixes, enhancements and it would be good to have a plan to  with a 1.5.x, 1.6.x roadmap that supports releasing this code independent of the time it will take to redo the MOP.

I don't agree with the assumption that performance is the number 1 cause for the failure to adopt Groovy. It may be for those writing scripts. However, in the USA at least, Eclipse support is easily a much bigger issue. When you get past people like those who contribute to OSS (a small, small subset of the overall programming population) most programmers I encounter don't spend much time writing scripts. For app dev work, these folks never get to the point of experiencing performance problems because they don't have all of the functionality in Eclipse with Groovy that they have with Java. Without that, they're just not interested - not matter how good the IntelliJ plugin is. For most organizations, switching IDE's to support Groovy is not an option. Based on the feedback I get from Java programmers when I present on Groovy, that is the number 1 impediment for broader Groovy adoption.

Scott

----- Original Message ----
From: Graeme Rocher <graeme@...>
To: dev@...
Sent: Monday, December 17, 2007 7:56:44 AM
Subject: Re: [groovy-dev] Tentative Roadmap


I'm in agreement with the two Alex's, our focus right now has to be

1) Performance
2) Java Integration

Forget the other shit, it quite simply should sit on the back burner
until these two are sorted. These 2 things are quite simply the 2 most
important aspects of Groovy's future.

Performance is the number 1 cause for the failure to adopt Groovy.
Java integration is the number 1 selling point differentiating it from
other languages

We need to continue with the 1.5.x series of bug fixes releases and
start now (and I mean now) on the work on the MOP to gain optimal
performance and be up there with the best performing dynamic languages
on the VM. Otherwise we will start to build a reputation (of bad
performance) that will be hard to shake off later.

In terms of breaking changes those using ExpandoMetaClass should not
suffer any. ie I should be able to upgrade Grails to the new MOP with
minimal fuss

Cheers

On Dec 17, 2007 11:15 AM, Guillaume Laforge <glaforge@...> wrote:
> That's the prerogative of the despot of the project.
>
> If we include Gant, we could also integrate Grails directly into
> Groovy, as a lot of people are doing Grails web-apps, and for the
 guys

> using Windows, I think we should also make Scriptom part of Groovy by
> default.
> Also, Groovy users also need to interact with Web Services, so we
> should embed Groovy-WS as well, with its hundreds of JARs from CXF,
> and XML-RPC, because SOAP is not all.
> Etc, etc...
>
> It doesn't make sense to bloat Groovy with things which should have
> their own lifecycle and dependencies.
> On the contrary, as outlined at GDC#4, the idea would be more to
> provide a modular approach by removing or externalizing things. For
> instance, not everybody needs the Swing support, the JMX support or
> the SQL support.
>
> And also see how stuck Sun is with all their deprecated APIs, it's

 not
> an example I'd wish to follow.
>
>
>
> On Dec 17, 2007 12:11 PM, Alex Tkachman <alex.tkachman@...>
 wrote:
> > Well, it was well-argumented. Thank you!
> >
> >
> > On Dec 17, 2007 2:06 PM, Guillaume Laforge <glaforge@...>
 wrote:
> > > No, we won't include Gant into Groovy.
> > >
> > >
> > > On Dec 17, 2007 11:59 AM, Alex Tkachman <alex.tkachman@...>
 wrote:
> > > > Regarding putting features like concurrency to in to additional
 module
> > > > I have absolutely vice versa suggestion. I think functionality
 like
> > > > Gant and good concurrency/actors package will not bloat Groovy
 but
> > > > provide best one shop expirience for Groovy users.
> > > >
> > > > So I suggest to include Gant in to main Groovy distro. Of
 course, if
> > > > Russel and other Gant developers like the idea.
> > > >
> > > >
> > > > On Dec 17, 2007 12:40 PM, Guillaume Laforge
 <glaforge@...> wrote:
> > > > > On Dec 17, 2007 10:25 AM, Alexandru Popescu ☀
> > > > > <the.mindstorm.mailinglist@...> wrote:
> > > > > > Firstly I would like to thank Mr.G and Jochen for setting
 up such a
> > > > > > detailed roadmap.
> > > > >
> > > > > You're welcome :-)
> > > > >
> > > > > > Now, I would like to add my opinion about it (opinion that
 might not
> > > > > > match exactly the above plan).
> > > > >
> > > > > At least, it's not in contradiction with the roadmap!
> > > > >
> > > > > > I do consider that the Groovy language has become "enough"
 feature
> > > > > > rich. IMO, the most important aspects for the future of the
 language
> > > > > > are now more in terms of usability. I don't think I can
 come out with
> > > > > > a nice proposal as you did, but my suggestion would be that
 the work
> > > > > > should focus on the following directions:
> > > > > >
> > > > > > 1/ fixing bugs related to the 1.5 major release. This will
 probably
> > > > > > result in a couple more minor releases.
> > > > >
> > > > > Agreed, this is what the 1.5.x releases are for.
> > > > >
> > > > > > 2/ focus on the performance. As discussed at GDC this
 mostly means
> > > > > > rethinking the whole MOP, stabilizing and unifying the MOP,
 etc. I
> > > > > > would definitely see the whole energy of the Groovy people
 going this
> > > > > > direction only for the next period.
> > > > >
> > > > > It's going to be a long process I suspect, as various
 experiments will
> > > > > have to be done, lots of discussions, a nice general proposal
 of what
> > > > > we really want, etc. So it's something that is going to be
 done in
> > > > > parallel to the progress we make in 1.x.
> > > > >
> > > > > > Probably the only "new" feature that I see as belonging to
 "usability"
> > > > > > is the multi-assignment, but this is just a nice to have
 one, so it
> > > > > > shouldn't focus on it right away (or at least I wouldn't
 consider it
> > > > > > as a strict goal for the next immediate period).
> > > > >
> > > > > I tried to put certain features at certain milestones, but we
 can
> > > > > certainly reorder the priorities.
> > > > > I've put multiple assignments early in the roadmap because we
 had
> > > > > promised them in 1.1/1.5, but as they're certainly not
 critical, we
> > > > > can postpone them to a latter release, it's not really
 critical.
> > > > >
> > > > > In the new features, there are things which should be
 discussed for
> > > > > inclusion or not.
> > > > > For instance, anonymous inner classes, nested classes and co.
> > > > > Initially, in the early days of Groovy, we didn't want to
 support them
> > > > > because we found them ugly, and closures should be used more
 to fill
> > > > > in the gap.
> > > > > So, it's perhaps a debate we should have as to whether the
 Groovy
> > > > > users really want them in the language?
> > > > >
> > > > > Regarding other features, for instance AST Transformations,
 we can
> > > > > already do that today, but in a more convoluted way (through
 the
> > > > > Groovy classloader), so it's mainly about making this feature
 easier
> > > > > to use. And for the concurrency feature, it could even just
 be an
> > > > > additional module, instead of bloating Groovy core with yet
 another

> > > > > big feature.
> > > > >
> > > > > > Hope you don't mind expressing my thoughts here,
> > > > >
> > > > > On the contrary, thanks for sharing your thoughts!
> > > > >
> > > > > --
> > > > >
> > > > > Guillaume Laforge
> > > > > Groovy Project Manager
> > > > > G2One, Inc. Vice-President Technology
> > > > > http://www.g2one.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Guillaume Laforge
> > > Groovy Project Manager
> > > G2One, Inc. Vice-President Technology
> > > http://www.g2one.com
> > >
> >
>
>
>
> --
>
> Guillaume Laforge
> Groovy Project Manager
> G2One, Inc. Vice-President Technology
> http://www.g2one.com
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com




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

    http://xircles.codehaus.org/manage_email

[Warner Onstine-3]

On Dec 17, 2007 1:32 PM, Guillaume Laforge <glaforge@...> wrote:

> On Dec 17, 2007 8:42 PM, Warner Onstine <warnero@...> wrote:
> > On Dec 16, 2007 6:25 PM, Andres Almiray <aalmiray@...> wrote:
> > >
> > > Looks great, specially the incremental compiler as we would definitely use it
> > > at work too.
> > > I wonder where does handling private access fall? as well as possibly
> > > allowing < <= => > to be overridden independently of <=>
> >
> > +1 on this. Honestly this one little omission really hamstrings Groovy
> > in certain respects and I would love to see method
> > overloading/overriding become complete (I have at least one bug on
> > this and have voted for another).
>
> If you can make sure that these bugs you mention are scheduled for
> 1.6, that would be very helpful.

Here are the two I was referring to:
http://jira.codehaus.org/browse/GROOVY-1889
http://jira.codehaus.org/browse/GROOVY-1838 (not as important, but irritating)

Neither are currently scheduled for a specific release.

-warner

>
> > Other than that I think the roadmap looks good.
>
> Thanks :-)
>
> --
> 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
>
>

--
Warner Onstine - Programmer/Author
New book on Tapestry 4!
Tapestry 101 available at
http://sourcebeat.com/books/tapestrylive.html
warner@...
http://warneronstine.com/blog

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

    http://xircles.codehaus.org/manage_email

[Andrew Gaydenko]

======= On Tuesday 18 December 2007, Scott Hickey wrote: =======
> I don't agree with the assumption that performance is the number 1 cause
> for the failure to adopt Groovy.

Sure. I think, a code must (order by importance desc)

1. be readable (specification fits expectations)
2. to work  (bugs-free)
....
xyz. be more or less efficient (performance)

Performance means nothing without 1. and 2.


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

    http://xircles.codehaus.org/manage_email

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

I will second that.  I think that a *huge* impediment to adoption of
Groovy at this point is the toolset.  And don't get me wrong - it is
*almost* there.  Once you get from *almost* to
*really-cool-Eclipse-plugin*, you bring in the whole set of people who
use Eclipse, and you put pressure on JDeveloper and NetBeans to follow
suit.  

Groovy, as a language, is here.  The supporting ensemble - Grails, Gant,
et. al. - are here.  The last step to get everyone to adopt is IDE
integration, and believe me, like Scott said - in the US, you are
measured on Eclipse.  


Jason Smith

-----Original Message-----
From: Scott Hickey [mailto:jshickey@...]
Sent: Monday, December 17, 2007 3:03 PM
To: dev@...
Subject: Re: [groovy-dev] Tentative Roadmap

...

I don't agree with the assumption that performance is the number 1 cause
for the failure to adopt Groovy. It may be for those writing scripts.
However, in the USA at least, Eclipse support is easily a much bigger
issue. When you get past people like those who contribute to OSS (a
small, small subset of the overall programming population) most
programmers I encounter don't spend much time writing scripts. For app
dev work, these folks never get to the point of experiencing performance
problems because they don't have all of the functionality in Eclipse
with Groovy that they have with Java. Without that, they're just not
interested - not matter how good the IntelliJ plugin is. For most
organizations, switching IDE's to support Groovy is not an option. Based
on the feedback I get from Java programmers when I present on Groovy,
that is the number 1 impediment for broader Groovy adoption.

Scott


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

    http://xircles.codehaus.org/manage_email

[Jörg Staudemeyer-2]

2007/12/17, Guillaume Laforge <glaforge@...>:

On Dec 17, 2007 8:30 PM, Jörg Staudemeyer <jstaudemeyer@...> wrote:
> Hi Guillaume ...
>
> 2007/12/17, Guillaume Laforge <glaforge@...>:
> > Dear Groovy developers,
>
> why do you address Groovy developers only? Looks a bit as if you make Groovy
> for yourselves and not for users.

You're serious? LOL :-)
I guess if I were doing Groovy just for myself or ourselves, I
wouldn't care about the bugs users report, or feature requests users
make. You'd notice a huge difference in the quality of the project and
you would not be using it :-)
You know, what this roadmap is mainly about what users requested over
the course of time.

Sorry, my objection was not meant to be that provocative. I know Groovy and I said "it looks like" and not "it is".
But nevertheless, I see no reasons not to invite users directly to take part in this discussion.

Having said that, I also would like to make some suggestions - all none-functional. New users are already swamped by Groovy's features and my impression is, Groovy should be rounded off, made better understandable, more reliable, faster and not so much more blown up.

That seems to comply with the main targets of you generally very convincing roadmap, at least until 1.9. But there are still some points missing:

1. A complete API documentation. There's still a lot of work to be done.
2. A complete language specification. There seems to be none at all.
3. Improved test coverage. I know there are many tests, but obviously not sufficient, otherwise many Jira issues could be prevented.
4. A well definied development process. Currently there seems to be no clear path from the idea of an improvement to its implementation - which artefacts have to be created, who decides when on what, how is quality assurance to be done and so on. Everyone can see how Groovy is made, so this is important to improve reliability in the users eyes.

Just a proposition.
-Jörg

[Jörg Staudemeyer-2]

2007/12/17, Chris Dempsey <cdallas@...>:

Would you be stunned of Microsoft decided among its developers what the roadmap for Windows before letting the world know?

I'd be stunned if Microsoft produced things to please their developers and not to make money. And to know what will be selling well they must ask their users (not necessarily the whole world).

Microsoft's business surely is very different from an open source project that depends on the enthusiasm of its contributors. But nevertheless, to be successful even open source projects should not lose sight of its end users. (The Groovy project is definitely aware of that, even if some discussions in the dev list leave doubts...).

-Jörg
An end user

[Gavin Grover]

----- Original Message ---- On 12/17/07, Guillaume Laforge wrote:
> On the contrary, as outlined at GDC#4, the idea would be more to
> provide a modular approach by removing or externalizing things. For
> instance, not everybody needs the Swing support, the JMX support or
> the SQL support.

A modular approach within the core, not just external to it, would help us who'd like to replace parts of Groovy with our own functionality. E.g. I've been writing a lexer/parser, with my own syntax, for the Groovy AST, so maybe those nodes could be part of Groovy's public interface. It would also be nice if the DGM methods were easily pluggable.
 
Cheers, Gavin Grover





      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

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

    http://xircles.codehaus.org/manage_email

[Andres Almiray]

+1

Let's avoid the stigma that followed Java 1.0/1.1 (in terms of performance) and do not bloat core with modules that albeit common are not part of the language per-se, otherwise we risk getting in the same trouble as the current JRE (and the jsr to break it into modules).

Graeme Rocher-2 wrote:

I'm in agreement with the two Alex's, our focus right now has to be

1) Performance
2) Java Integration

Forget the other shit, it quite simply should sit on the back burner
until these two are sorted. These 2 things are quite simply the 2 most
important aspects of Groovy's future.

Performance is the number 1 cause for the failure to adopt Groovy.
Java integration is the number 1 selling point differentiating it from
other languages

We need to continue with the 1.5.x series of bug fixes releases and
start now (and I mean now) on the work on the MOP to gain optimal
performance and be up there with the best performing dynamic languages
on the VM. Otherwise we will start to build a reputation (of bad
performance) that will be hard to shake off later.

In terms of breaking changes those using ExpandoMetaClass should not
suffer any. ie I should be able to upgrade Grails to the new MOP with
minimal fuss

Cheers

On Dec 17, 2007 11:15 AM, Guillaume Laforge <[e-mail]> wrote:
> That's the prerogative of the despot of the project.
>
> If we include Gant, we could also integrate Grails directly into
> Groovy, as a lot of people are doing Grails web-apps, and for the guys
> using Windows, I think we should also make Scriptom part of Groovy by
> default.
> Also, Groovy users also need to interact with Web Services, so we
> should embed Groovy-WS as well, with its hundreds of JARs from CXF,
> and XML-RPC, because SOAP is not all.
> Etc, etc...
>
> It doesn't make sense to bloat Groovy with things which should have
> their own lifecycle and dependencies.
> On the contrary, as outlined at GDC#4, the idea would be more to
> provide a modular approach by removing or externalizing things. For
> instance, not everybody needs the Swing support, the JMX support or
> the SQL support.
>
> And also see how stuck Sun is with all their deprecated APIs, it's not
> an example I'd wish to follow.
>
>
>
> On Dec 17, 2007 12:11 PM, Alex Tkachman <[e-mail]> wrote:
> > Well, it was well-argumented. Thank you!
> >
> >
> > On Dec 17, 2007 2:06 PM, Guillaume Laforge <[e-mail]> wrote:
> > > No, we won't include Gant into Groovy.
> > >
> > >
> > > On Dec 17, 2007 11:59 AM, Alex Tkachman <[e-mail]> wrote:
> > > > Regarding putting features like concurrency to in to additional module
> > > > I have absolutely vice versa suggestion. I think functionality like
> > > > Gant and good concurrency/actors package will not bloat Groovy but
> > > > provide best one shop expirience for Groovy users.
> > > >
> > > > So I suggest to include Gant in to main Groovy distro. Of course, if
> > > > Russel and other Gant developers like the idea.
> > > >
> > > >
> > > > On Dec 17, 2007 12:40 PM, Guillaume Laforge <[e-mail]> wrote:
> > > > > On Dec 17, 2007 10:25 AM, Alexandru Popescu ☀
> > > > > <[e-mail]> wrote:
> > > > > > Firstly I would like to thank Mr.G and Jochen for setting up such a
> > > > > > detailed roadmap.
> > > > >
> > > > > You're welcome :-)
> > > > >
> > > > > > Now, I would like to add my opinion about it (opinion that might not
> > > > > > match exactly the above plan).
> > > > >
> > > > > At least, it's not in contradiction with the roadmap!
> > > > >
> > > > > > I do consider that the Groovy language has become "enough" feature
> > > > > > rich. IMO, the most important aspects for the future of the language
> > > > > > are now more in terms of usability. I don't think I can come out with
> > > > > > a nice proposal as you did, but my suggestion would be that the work
> > > > > > should focus on the following directions:
> > > > > >
> > > > > > 1/ fixing bugs related to the 1.5 major release. This will probably
> > > > > > result in a couple more minor releases.
> > > > >
> > > > > Agreed, this is what the 1.5.x releases are for.
> > > > >
> > > > > > 2/ focus on the performance. As discussed at GDC this mostly means
> > > > > > rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> > > > > > would definitely see the whole energy of the Groovy people going this
> > > > > > direction only for the next period.
> > > > >
> > > > > It's going to be a long process I suspect, as various experiments will
> > > > > have to be done, lots of discussions, a nice general proposal of what
> > > > > we really want, etc. So it's something that is going to be done in
> > > > > parallel to the progress we make in 1.x.
> > > > >
> > > > > > Probably the only "new" feature that I see as belonging to "usability"
> > > > > > is the multi-assignment, but this is just a nice to have one, so it
> > > > > > shouldn't focus on it right away (or at least I wouldn't consider it
> > > > > > as a strict goal for the next immediate period).
> > > > >
> > > > > I tried to put certain features at certain milestones, but we can
> > > > > certainly reorder the priorities.
> > > > > I've put multiple assignments early in the roadmap because we had
> > > > > promised them in 1.1/1.5, but as they're certainly not critical, we
> > > > > can postpone them to a latter release, it's not really critical.
> > > > >
> > > > > In the new features, there are things which should be discussed for
> > > > > inclusion or not.
> > > > > For instance, anonymous inner classes, nested classes and co.
> > > > > Initially, in the early days of Groovy, we didn't want to support them
> > > > > because we found them ugly, and closures should be used more to fill
> > > > > in the gap.
> > > > > So, it's perhaps a debate we should have as to whether the Groovy
> > > > > users really want them in the language?
> > > > >
> > > > > Regarding other features, for instance AST Transformations, we can
> > > > > already do that today, but in a more convoluted way (through the
> > > > > Groovy classloader), so it's mainly about making this feature easier
> > > > > to use. And for the concurrency feature, it could even just be an
> > > > > additional module, instead of bloating Groovy core with yet another
> > > > > big feature.
> > > > >
> > > > > > Hope you don't mind expressing my thoughts here,
> > > > >
> > > > > On the contrary, thanks for sharing your thoughts!
> > > > >
> > > > > --
> > > > >
> > > > > Guillaume Laforge
> > > > > Groovy Project Manager
> > > > > G2One, Inc. Vice-President Technology
> > > > > http://www.g2one.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Guillaume Laforge
> > > Groovy Project Manager
> > > G2One, Inc. Vice-President Technology
> > > http://www.g2one.com
> > >
> >
>
>
>
> --
>
> Guillaume Laforge
> Groovy Project Manager
> G2One, Inc. Vice-President Technology
> http://www.g2one.com
>



--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com