On 06/22/2016 07:45 PM, Jochen Theodorou wrote:
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?
Well, it was a 140 pages about Groovy language compared to the Java
language as well as Grails. Basically I went through all of the new
things language Groovy provided that was lacking in Java and how it was
more consice, expressive and dangerously powerful in the wrong hands.
Grails I went through basically the same things. It was around 70 pages
on each. Pretty quick guide to both actually. Nothing research worthy
maybe, but hey it was only a thesis :P
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.
Yes, personally I like the name, but a couple of times i've mentioned it
to people that haven't heard about it and I realize how "stupid" the
name sounds and how unserious what I am proposing sounds like.
Maybe it's time for a completely new name, possibly even a new
foundation. Just start over with JDK 9, and start forking and
implementing Groovy syntax first on top of it, like elvis, safe nav,
closure syntax, multiline strings, GStrings, default public, no
semicolon, no parantheses, scripting capability, default getters and
settings, default constructors. That to me is Java with some elegant
syntax.
Then you could move to providing a safe and static AST injections of
things. public SomeClass Overrides java.util.ArrayList {...}, seems like
neat syntax to me. Then one could read them at time compile time, and
replace the original ArrayList on a per jar file. If a jar imports or
uses another modified module it would have access to those added methods
for instance. It can still override methods just for it's own use.
One shouldn't be able to override another libraries function. I think
that's just dangerous and rarely makes any sense.
[...]
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 a Java fork would be almost 1:1, if all it generated was Java like
code. I think the performance issues is the invokeDynamic calls that
groovy does internally, and they might not necessarily be needed.
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.
Yes, this also got me thinking of another thing. The difference between
runtime and checked exceptions in Java or other languages actually does
not make any sense at all.
In Java if a method throws a checked exception, it can either handle it
right there, or throw it. Most exceptions is to be bubbled up, to the
original caller. If a user calls a method that say chain calls 20 other
methods, each and one of those methods has to declare that exception on
their declaration. That is so fucking ugly. Furthermore, issue becomes
even bigger when you have to go through interfaces and abstract classes,
then you have to convert them to Runtime Exceptions basically, if you
don't want to handle them which again makes little sense.
The thing with checked exceptions, is that the compiler should and can
already infer what expceptions can be thrown by any call, so the need to
declare it on a each method, is largely informative, it is like
commenting that method can throw an IOException wrapped in a
RuntimeException. The comment can disappear so Java has forced us to
declare it on the method.
However, any editor could in principle, and in theory tell you on any
call, what exceptions can be thrown and what kind of exceptions you
could choose to handle. Ofcourse that would result in many exceptions
often but the need to declare them on each method is largely syntatical
and ugly. If a method throws an exception that is not managed, the
editor would tell you that there is an error, generate a trycatch, or
throw it. The compile it self can therefore keep track of what
exceptions a method actually throws so there is no need for a throws
declaration.
Regarding interfaces and abstract methods one should always assume that
an exception can occur, what they are or not are is hidden either way.
If there is a declaration of someform of exception being thrown, then
one can handle that explitly, otherwise, it could be any exception
disguised as a runtime or handled anyway.
Also, a language should be able to return multiple things by default.
For instance, this is something like that I've implemented in Java that
is used on occasion.
public final class Return {
private Return() {}
public static final class $2<$1, $2> {
public $1 $1;
public $2 $2;
public $2($1 $1, $2 $2) {
this.$1 = $1;
this.$2 = $2;
}
}
public static final class $3<$1, $2, $3> {
public $1 $1;
public $2 $2;
public $3 $3;
public $3($1 $1, $2 $2, $3 $3) {
this.$1 = $1;
this.$2 = $2;
this.$3 = $3;
}
}
public static final class $4<$1, $2, $3, $4> {
public $1 $1;
public $2 $2;
public $3 $3;
public $4 $4;
public $4($1 $1, $2 $2, $3 $3, $4 $4) {
this.$1 = $1;
this.$2 = $2;
this.$3 = $3;
this.$4 = $4;
}
}
public Returns.$2<String, Integer> exampleMethod() {
return new Returns.$2<>("MyName", 32);
}
Ofcourse this is the best syntax available in Java to do this. A custom
language, could support a much nicer syntax.
public String, Integer exampleMethod() {
"MyName", 20
}
String name, Integer age = exampleMethod();
I hope i am not going to much about my fantasies and ideas, there is
much more too :)
[...]
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
