Re: [groovy-dev] Tentative Roadmap
+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 <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
>
>
--
--
View this message in context: http://www.nabble.com/Tentative-Roadmap-tp14368039p14401055.html
Sent from the groovy - dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
RSS Feed