Hi Alex,

Very good summary of the situation, and what's involved!
Thanks a lot for this great wrap-up.
Now we have a thread to point people at when the question comes again
and again :-)

I'm also on the same wave-length as Paul and Jochen on all this.

People can already use gpp today if they so desire, as it's been
designed as an "extension".
With Groovy 1.7.5 out soon, you shouldn't even have to do the custom
distros, which will be simpler / easier for you (and for the users) --
although we still have to come back on the file extension mechanism,
if we want to have it in 1.7.5!
And with Groovy becoming more modular, with a smaller core, etc (still
lots of work to do here too), we won't really bother about
"integration" anymore, but everybody will use the pieces they need for
their own puzzle!

My usual worry (and I've already expressed it a few times) is that gpp
is "not exactly" Groovy: it's using the same syntax as Groovy... but
has some different semantics in various areas (no multimethods,
different groovy truth, additional tricks or operators, etc).
That's why it often appears (perhaps wrongly as you explained) as a
different Groovy, ie. a new language, or even a competitor.
I wish as gpp grows older that the differences in semantics will be
reduced as much as possible, so that both languages are really as
close as possible, and don't generate loads of backward-compatibility
issues for our huge community.

It took a lot of time for Groovy to really become a "1.0" (with our
high expectations).
It should be a little easier for Groovy++ as it builds upon the
shoulders of Groovy, but it'll need some more time to continue towards
reducing the semantic gaps and become a great extension for gaining
those last milliseconds we need sometimes.
So keep up the pace, and with more feedback and users, it'll get there
sooner rather than later!

Thanks again for this summary.

Guillaume



On Fri, Sep 3, 2010 at 08:33, Alex Tkachman <alex.tkachman@(protected):
> These are two very important questions, which surprisingly leads to
> that same answer. So I cross post in to Groovy User List as well.
>
> The questions are
> -  if there is a future possibility of merging Groovy++ into standard Groovy?
> -  Or of an integration strategy where the Groovy++ jars are
> complimentary to the standard Groovy jars instead of replacing them?
>
> Let me start with facts.
>
> Fact number one - Groovy++ is not competitor or replacement of Groovy.
> Groovy++ is our way to make Groovy more competitive in the booming
> polyglot world (JRuby/Scala/Clojure). There is no intention to replace
> Groovy. The intention is to extend areas where it is applicable. The
> most important value of Groovy++ are performance critical and highly
> concurrent applications and big manageable and refactorable codebases.
>
> Fact number two - Groovy++ binaries should not replace Groovy
> binaries. By design (thanks to great architecture of Groovy)  you just
> need to add G++ jar in to your class path and that's it. We are not
> 100% here yet. Only 98% :) Two remaining pieces are
> - G++ requires not yet released Groovy 1.7.5 because of some bug fixes
> done there
> - G++ has experimental feature (.gpp file extension where you don't
> need to use @Typed at all) which require some support from Groovy core
> and we stil did not find yet nice way to integrate it in to the core.
> So as of now we need to apply tiny patch for that and have our own
> build of 1.7.5. These issue under close investigation and hopefully
> will be resolved before 1.7.5 released
>
> Fact number three - there is close cooperation between both projects
> in many areas
> - both me and Roshan are comitters in Groovy Core.
> - Dierk helps us a lot with language design issues by pushing hardly
> to keep semantic as close as possible to regular Groovy and advising
> on really delicate language matters.
> - Graeme's teach and advice on managing community in open-source way.
> - Friendly critique by Guillaume and Jochen (even when we are totally
> disagree or it looks sometime that we have battle) helps us a lot to
> define right line of evolution
> - Already now we have serious discussions about possibility of
> contributing in to Groovy Core our implementation of traits (most
> likely will be part of 1.8.0) and how knows what will be the next.
>
> Fact number four - It is a bit too earlier to think about integrating
> Groovy++ in to Groovy Core right now. G++ is still very young project.
> It was started less than a year ago as experiment. Obviously we did
> long way since that time - we have working compiler, interesting
> library, Grails integration, lightweight Gretty framework and slowly
> start gaining some popularity. Another obvious thing is that we still
> need more freedom to experiment with language features than possible
> in already widely used Groovy Core. My personal belief is that Groovy
> 2.0 design time (we expect a lot of breaking changes at that moment
> anyway) will be exactly very right time to consider such integration.
> I am sure at that moment we will have stable and widely used Groovy++
> 1.x out. What would help a lot in mean time if Groovy++ would be seen
> as friend and equal member of Groovy eco-system and not as competitor.
>
> Fact number five (philosophical one so controversial) - you can not
> copy/paste code between statically and dynamically typed parts without
> being careful. The problem here is not only because G++ allows you a
> bit richer syntax (mixed mode, less need for 'as' keyword, traits,
> []/[:]-syntax for constructors - theoretically all these features are
> supportable in dynamic groovy at least to some extent) The real
> problem is just very different nature of static and dynamic dispatch.
> Rough analogy can be C/C++ compile-time define which can totally
> change behavior of your code. Some people believe that it can lead to
> confusion of not enough experienced users. I personally don't share
> these concern and think that professionals know very well how to deal
> with such problems.
>
> My conclusions are the following
> - Groovy++ is friendly younger brother of Groovy and the projects are
> influenced in both directions
> - There is definitely possibility of merging Groovy++ in to Groovy
> Core in the future. I think most logical time to consider such merge
> will be Groovy 2.0 design time
> - The integration strategy where the Groovy++ jars are complimentary
> to the standard Groovy jars instead of replacing them are exactly by
> design and coming in to reality very soon.
>
> I would really appreciate comments/opinions of other developers of
> Groovy Core on that line of reasoning. Guillaume, Roshan, Jochen,
> Dierk, Graeme, Paul, Anders, Peter, please-please-please share your
> thoughts. Sorry if I forgot someone.
>
> Best regards
> Alex
>
> On Fri, Sep 3, 2010 at 3:31 AM, Ben <benlperkins@(protected):
>> First off I'd just like to say how happy I was to learn about the
>> Groovy++ project.  I enjoy Groovy syntax but there are definitely
>> times where I'd prefer to have the greater performance and compiler-
>> sanity of static typing.  Thanks for all the work you're putting into
>> it.
>>
>> I'm curious if there is a future possibility of merging Groovy++ into
>> standard Groovy?  Or of an integration strategy where the Groovy++
>> jars are complimentary to the standard Groovy jars instead of
>> replacing them?
>>
>> Thanks!
>> Ben
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

  http://xircles.codehaus.org/manage_email