« Return to Thread: Tentative Roadmap
Re: Tentative Roadmap
by glaforge
::
Rate this Message:
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
<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 |
