groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mr Andersson <mr.andersson....@gmail.com>
Subject Re: Is it possible to enable CompileStatic for an entire project
Date Fri, 24 Jun 2016 16:12:18 GMT


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
>


Mime
View raw message