On 22.06.2016 18:55, Mr Andersson wrote:
[...]
We, at our company can only ship groovy if it is fully static, no way to
manipulate. It's difficult to hammer it through otherwise. Big
enterprise JEE companies don't take risks, especially when the tools are
handed over to 5 000 dev across the globe.
We have to know that nobody will start utility the crazy ( but neat )
features of the dynamic parts of Groovy, but we like that it is such a
powerful language, and easy to learn for any java developer that it
would be a smash hit.
yeah, I have a lot of plans in a direction that allows more control
about the runtime meta programming and actually allows classes to
immunize themselves against meta class changes. The basic concept and
the ideas are there, the detail work and a good plan to migrate current
Groovy to that version is very difficult to do.
[...]
I had alot of useful code that I can never use or pull out, because it's
just to dynamic. Over time one starts to realize how important it is to
know at compile time that things will work.
do you have a different Java than I have? No seriously, even with the
infamous Haskell I would not assume that my program is correct just
because it compiles.
[...]
I have been in love with this language, and even wrote my masters thesis
about it.
really?about what exactly?
It has so much potential, even to replace Java. It's power is it's
syntax and it's closeness to Java syntax.
Adoption in the Java community would be massive if it were more static.
And you tell that a person that did hear about people not accepting the
language already just because of the name. I know about cases in which a
company did not use a library because it is written in Groovy... just
because it is written in Groovy. All that would not change with static
compilation by default at all.
[...]
I am not sure how well, performance wise Groovy does compared with Java,
Scala, Kotlin, Ceylon and so on. If it is close, then I say just offer
us a static version with what you have. You are so close now.
static Groovy is on par most of the time, dynamic Groovy depends, but I
think it is more in the range of being 2.5 times java (100ms runtime
becomes 250ms). I think that is close enough.... and there is still some
potential
But I would still like to argue that maybe Groovy needs to be rewritten
from scratch in order to perform even better. But I know little about
this and have little experience with the @CompileStatic annotations
because I have been away from this language for so long.
For better performance of dynamic Groovy we need to rework the MOP. For
example not using exceptions for missing properties and such. But I say
this for too long already.
[...]
Groovy++ died, but at that time, the Israeli guy that pushed for it,
didn't deliver to the end, because probably he tried to utilize the core
groovy, but back then everyone was looking forward to it.
Eventually parts of it got absorbed into the Groovy core if iam not
mistaken.
Alex is a bright guy, good for new concepts, good for prototypes, but no
man for the detail work. That´s why groovy++ died. At no point did we
include source code from Groovy++. Concept wise the static compilation
we have now is not inspired by Groovy++. Groovy++ simply tried to apply
the static type system of Java, that was something we always did feel is
not good enough. In Groovy we are now using a limited form of inference
types, based on flow typing. Also an old concept, but normally not used
in that way. Of course Groovy++ had more to offer than just static
compilation. But again our traits are for example similar to what
Groovy++ had back then, but the concept is much more worked out and
actually based on what Scala did. I for example would also like to bring
the async/await concept from C# to Groovy... copying the juicy parts
from other languages is always something we did, if they fit.
bye Jochen
