« Return to Thread: Tentative Roadmap
Re: Tentative Roadmap
by Alex Tkachman
::
Rate this Message:
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
>
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
>
« Return to Thread: Tentative Roadmap
| Free embeddable forum powered by Nabble | Forum Help |
