Comparing Xtend to Java

[Sebastien Diot]

Now that I have my first (public) Xtend API working, I thought I'd write down where I think XTend still needs to work to catch up with Java:

1) Having to write:

myMeaningFullIdentifierName = myMeaningFullIdentifierName + 1

instead of;

myMeaningFullIdentifierName++ (or ++myMeaningFullIdentifierName)

When you have a lot of "myMeaningFullIdentifierName" (as I had in this API) to increment/count (no loop index here), this gets old quickly.

Since this is an "on purpose" feature of Xtend, there is no hope of it ever being "fixed" AFAIK.

2) Lack of inner, and in particular anonymous, classes (with the exception of lambdas)

I think this gets fixed in 2.5, which should come out in December, if I get it right.

3) Lack of "synchronized" keyword

Know issue: doesn't seem to bother anyone except me. I worked around it with a Java base class.

4) Lack of inheritance of @Data types.

Maybe I am just missing something here... Java hasn't got an @Data, but not having inheritance partly cancels out the benefits, I think. But as I will probably write my own alternative to @Data, this is only a short-term issue for me.

5) No "break" in loops.

So far, I could use a "return" as an alternative, but this isn't always possible.

There are many new features in Xtend that Java misses, but it takes a while to learn to use them, to get the full benefit of Xtend. OTOH, seeing things that are totally normal in Java, and used 100 times a day (increment operator, inner classes) missing in Xtend just "jumps in your face", as a Java programmer. I don't think any amount of "discussing" would ever convince me that removing ++ and -- (which should be basically "free" language features, since they are already defined in Java) is in any way a "good thing" (same think for the "break" keyword, but I use ++ far more often). The ++ and -- operators match one-to-one assembler instructions of the processor which allows to write efficient code; removing them because "it's not functional" is not a convincing argument for me.

Regards,
Sebastien

[Stefan Oehme]

Am Samstag, 7. Dezember 2013 01:09:29 UTC+1 schrieb Sebastien Diot:

Now that I have my first (public) Xtend API working, I thought I'd write down where I think XTend still needs to work to catch up with Java:

1) Having to write:

myMeaningFullIdentifierName = myMeaningFullIdentifierName + 1

instead of;

myMeaningFullIdentifierName++ (or ++myMeaningFullIdentifierName)

When you have a lot of "myMeaningFullIdentifierName" (as I had in this API) to increment/count (no loop index here), this gets old quickly.

Since this is an "on purpose" feature of Xtend, there is no hope of it ever being "fixed" AFAIK.

Okay, I really think that ++ is the source of many bugs. But I agree that x+=1 would be nice to have. But that's probably not possible, because it would be ambiguous in Xtend. It could either be an assignment statement or it could be an expression with the "+=" operator.

 

3) Lack of "synchronized" keyword

 

You can write your own little active annotation for that.

 

4) Lack of inheritance of @Data types.

Maybe I am just missing something here... Java hasn't got an @Data, but not having inheritance partly cancels out the benefits, I think. But as I will probably write my own alternative to @Data, this is only a short-term issue for me.

Last time I tried them, @Data types supported inheritance, what exactly doesn't work for you? BTW, subclassing and immutability don't mix well, so I actually believe that @Data should forbid inheritance ;)

 

5) No "break" in loops.

So far, I could use a "return" as an alternative, but this isn't always possible.

I always find that break and continue make loops hard to read. Pretty much any case I've seen could be replaced either with "return" or with an if-statement. 

The ++ and -- operators match one-to-one assembler instructions of the processor which allows to write efficient code

The JIT compiler will replace x = x + 1 with inc. So you are actually not optimizing anything. 

[Sebastien Diot]

On Saturday, December 7, 2013 11:39:31 AM UTC+1, Stefan Oehme wrote:

Am Samstag, 7. Dezember 2013 01:09:29 UTC+1 schrieb Sebastien Diot:

Now that I have my first (public) Xtend API working, I thought I'd write down where I think XTend still needs to work to catch up with Java:

1) Having to write:

myMeaningFullIdentifierName = myMeaningFullIdentifierName + 1

instead of;

myMeaningFullIdentifierName++ (or ++myMeaningFullIdentifierName)

When you have a lot of "myMeaningFullIdentifierName" (as I had in this API) to increment/count (no loop index here), this gets old quickly.

Since this is an "on purpose" feature of Xtend, there is no hope of it ever being "fixed" AFAIK.

Okay, I really think that ++ is the source of many bugs. But I agree that x+=1 would be nice to have. But that's probably not possible, because it would be ambiguous in Xtend. It could either be an assignment statement or it could be an expression with the "+=" operator.

Could we then not have something non-ambiguous like inc(var,increment defaulting to 1)? It doesn't have to be "++"; I just want something short where the variable doesn't need to be repeated.
 

 

3) Lack of "synchronized" keyword

 

You can write your own little active annotation for that.

I know; I think it can be gotten around relatively easily. It's just that there is an issue for it, but it doesn't look like it is likely to be fixed it the near future.
 

 

4) Lack of inheritance of @Data types.

Maybe I am just missing something here... Java hasn't got an @Data, but not having inheritance partly cancels out the benefits, I think. But as I will probably write my own alternative to @Data, this is only a short-term issue for me.

Last time I tried them, @Data types supported inheritance, what exactly doesn't work for you? BTW, subclassing and immutability don't mix well, so I actually believe that @Data should forbid inheritance ;)

I tried again within a simple test class, and it worked for me too :) ; I must have done something wrong, or maybe there was some other error at the same time, and the inheritance error was a side-effect.
 

 

5) No "break" in loops.

So far, I could use a "return" as an alternative, but this isn't always possible.

I always find that break and continue make loops hard to read. Pretty much any case I've seen could be replaced either with "return" or with an if-statement. 

This is a constant cause of arguments in our team at work. The boss thinks that "methods should only ever have one single return statement". The requirement is rather problematic, when combined with "only the 'new' for loop" and "you cannot use break" in Xtend. But I use Xtend privately, and so can use return where I want. The main problem with using return in this case, is that sometimes you want to return more then one value, which requires creating a temporary object. I really don't like that kind of short-lived garbage generation, because I think it could be avoided. The number of values you want to return is the number of variable *outside of the loop* that you would be manipulating in Java. the "return an object" with those variables in can be replaced with "pass a mutable object as parameter", but it still causes short-lived garbage.
 

The ++ and -- operators match one-to-one assembler instructions of the processor which allows to write efficient code

The JIT compiler will replace x = x + 1 with inc. So you are actually not optimizing anything. 

OK. That is news to me. :) Still my argument is that if you really need to increment something, you are going to do it anyway, and so removing the ++ operator, from the point of view of an Xtend user, just seems like a pointless "just so" limitation, like taking away the toys of a kid, in the hope he/she will start behaving better (I tried; it doesn't work :D  )

If I remember well, the lack of the ++ operator was justified by it "not being functional". If it's really a technical limitation of the syntax / compiler instead (ambiguity), I think it really should be expressed like that in the Xtend documentation / tutorial. But even better would be to offer a standard replacement syntax, that would not be ambiguous, IMO.


To recap, while I was being critical, I'm still quite happy with this first real Xtend project, and I intend to stick with Xtend unless I find a "blocker issue" down the road. I've been following Xtend for quite a while now, and so I can see that it is moving forward in what I consider to be the "right direction". The Killer Feature of Xtend for me are the Active Annotations. I intend to make heavy use of them, and without them, I might not have switched to Xtend at all. And what I'm waiting for, more then everything else, is the ability to *manipulate* the source code of existing methods in Active Annotations. I was using Scala at some point in the past, but manipulating the Scala source code with compiler plugins was a nightmare, which eventually led me to leave Scala behind. I've tried that in pure Java too, but if I remember well, I needed to write the code doing the manipulation *twice*; once for javac, and once for the Eclipse Java compiler, so I gave up on that as well.

[Stefan Oehme]

Am Samstag, 7. Dezember 2013 13:41:43 UTC+1 schrieb Sebastien Diot:

Could we then not have something non-ambiguous like inc(var,increment defaulting to 1)? It doesn't have to be "++"; I just want something short where the variable doesn't need to be repeated.

 

Well, thinking a bit more about it: Maybe we could give += special meaning for numbers and forbid overloading it for numbers. Of course this could break existing overloads, but I don't see a reason why anyone would have overloaded += for number types.  

 

 

3) Lack of "synchronized" keyword

 

You can write your own little active annotation for that.

I know; I think it can be gotten around relatively easily. It's just that there is an issue for it, but it doesn't look like it is likely to be fixed it the near future.

I guess when active annotations are out of beta status a @Synchronized annotation could be included in xtend.lib

 

5) No "break" in loops.

So far, I could use a "return" as an alternative, but this isn't always possible.

I always find that break and continue make loops hard to read. Pretty much any case I've seen could be replaced either with "return" or with an if-statement. 

This is a constant cause of arguments in our team at work. The boss thinks that "methods should only ever have one single return statement".

Tell your boss that he is misquoting an old rule from assembler programming that does not apply to Java. Of course there are good reasons to limit the number of return statements (makes refactoring very hard), but for short methods there is no reason why I shouldn't use a quick return. And break/continue is much worse than return ;)

 

The main problem with using return in this case, is that sometimes you want to return more then one value, which requires creating a temporary object.

I think having that temporary object is not bad at all, because later it may become a very useful class in its own right. And it makes it easier to refactor your loop or move parts of it into another class or whatever. The JVM is pretty damn good at garbage collection, so I worry much less about creating it. Of course, that doesn't count when you are writing a performance critical section. But in that case writing optimized code in pure Java is probably the way to go.

 

Still my argument is that if you really need to increment something, you are going to do it anyway, and so removing the ++ operator, from the point of view of an Xtend user, just seems like a pointless "just so" limitation, like taking away the toys of a kid, in the hope he/she will start behaving better (I tried; it doesn't work :D  )

 

I only have a problem with ++ when it is used inline (like if (a == i++)), because that is just plain unreadable. I have nothing against ++ as an assignment that returns void. But I think the above mentioned special handling for += would be even better. 

 

To recap, while I was being critical, I'm still quite happy with this first real Xtend project, and I intend to stick with Xtend unless I find a "blocker issue" down the road. I've been following Xtend for quite a while now, and so I can see that it is moving forward in what I consider to be the "right direction". The Killer Feature of Xtend for me are the Active Annotations. I intend to make heavy use of them, and without them, I might not have switched to Xtend at all. And what I'm waiting for, more then everything else, is the ability to *manipulate* the source code of existing methods in Active Annotations. I was using Scala at some point in the past, but manipulating the Scala source code with compiler plugins was a nightmare, which eventually led me to leave Scala behind. I've tried that in pure Java too, but if I remember well, I needed to write the code doing the manipulation *twice*; once for javac, and once for the Eclipse Java compiler, so I gave up on that as well.

Nice to hear you are as hooked as I am ;) Active annotations are definitely the killer feature that raises Xtend way above Java and many other languages. 

[Sven Efftinge]

Hi Sebastian,

thanks for the feedback. Comments inline.

On Dec 7, 2013, at 1:09 AM, Sebastien Diot <skunki...@googlemail.com> wrote:

> Now that I have my first (public) Xtend API working, I thought I'd write down where I think XTend still needs to work to catch up with Java:
>
> 1) Having to write:
>
> myMeaningFullIdentifierName = myMeaningFullIdentifierName + 1
>
> instead of;
>
> myMeaningFullIdentifierName++ (or ++myMeaningFullIdentifierName)

Yes, I would like to do that from time to time as well.
The main reason we haven't added it is that it's hard to solve this with operator overloading without full support for def-macros.
But I think we should discuss whether we want to hard-bake it into the language and replace with a library once that's possible.
Here's the corresponding feature request :

https://bugs.eclipse.org/bugs/show_bug.cgi?id=379178

> 2) Lack of inner, and in particular anonymous, classes (with the exception of lambdas)
>
> I think this gets fixed in 2.5, which should come out in December, if I get it right.

Yo, it didn't make it into 2.5 unfortunately, but this definitly on of the next language features we're going to

https://bugs.eclipse.org/bugs/show_bug.cgi?id=402388
https://bugs.eclipse.org/bugs/show_bug.cgi?id=376399

>
> 3) Lack of "synchronized" keyword

Agreed. Although relatively easy to ship your own lib, it should be there out-of-the-box.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=418753

> 4) Lack of inheritance of @Data types.

Should work. If you are able to reproduce the missbehavior please file bugzilla.

> 5) No "break" in loops.

Not a fan of this one. We don't even have a feature request for it so far.
You may open one and if you find enough supporters I'm open for discussion :-)

The only good argument I'm aware of, is the "jumps in your face" as a Java developer (see below).

Sven

[Sebastien Diot]

On Sunday, December 8, 2013 8:33:03 PM UTC+1, Sven Efftinge wrote:

> 2) Lack of inner, and in particular anonymous, classes (with the exception of lambdas)
>
> I think this gets fixed in 2.5, which should come out in December, if I get it right.

Yo, it didn't make it into 2.5 unfortunately, but this definitly on of the next language features we're going to

https://bugs.eclipse.org/bugs/show_bug.cgi?id=402388
https://bugs.eclipse.org/bugs/show_bug.cgi?id=376399

Any idea yet about an ETA for that?
 

>
> 3) Lack of "synchronized" keyword

Agreed. Although relatively easy to ship your own lib, it should be there out-of-the-box.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=418753

Also, I assume there is a similar request for volatile. I found that the lack of volatile is in fact harder to work around then the lack of synchronize.
You end-up with something like:
Concrete-Xtend-Class extends Work-Around-Java-Class-Just-For-The-Volatile extends Base-Xtend-Class
 

> 5) No "break" in loops.

Not a fan of this one. We don't even have a feature request for it so far.
You may open one and if you find enough supporters I'm open for discussion :-)

The only good argument I'm aware of, is the "jumps in your face" as a Java developer (see below).

I'll try to live without, and see how well I do.

[Sven Efftinge]

Comments inline

Am 08.12.2013 um 22:32 schrieb Sebastien Diot <skunki...@googlemail.com>:

On Sunday, December 8, 2013 8:33:03 PM UTC+1, Sven Efftinge wrote:

> 2) Lack of inner, and in particular anonymous, classes (with the exception of lambdas)
>
> I think this gets fixed in 2.5, which should come out in December, if I get it right.

Yo, it didn't make it into 2.5 unfortunately, but this definitly on of the next language features we're going to

https://bugs.eclipse.org/bugs/show_bug.cgi?id=402388
https://bugs.eclipse.org/bugs/show_bug.cgi?id=376399

Any idea yet about an ETA for that?

No, but at least anonymous classes are scheduled for 2.5. Which will come out in spring 2014.

 

>
> 3) Lack of "synchronized" keyword

Agreed. Although relatively easy to ship your own lib, it should be there out-of-the-box.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=418753

Also, I assume there is a similar request for volatile. I found that the lack of volatile is in fact harder to work around then the lack of synchronize.
You end-up with something like:
Concrete-Xtend-Class extends Work-Around-Java-Class-Just-For-The-Volatile extends Base-Xtend-Class

An active annotation should do it for now.

 

> 5) No "break" in loops.

Not a fan of this one. We don't even have a feature request for it so far.
You may open one and if you find enough supporters I'm open for discussion :-)

The only good argument I'm aware of, is the "jumps in your face" as a Java developer (see below).

I'll try to live without, and see how well I do.

Ok.

Sven

[Toby Kurien]

With regards to the synchronized keyword, it's in any case better to use ReentrantLock
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantLock.html

What would be great is if Xtend included a @Synchronized annotation that would implement the ReentrantLock automatically :-) It can default to using a static lock for static methods and an instance lock for normal methods. I'd like to add this to my Xtendroid project, but I'm not too good with the active annotations (Sven, maybe you can help? :)

[Stefan Oehme]

Am Dienstag, 10. Dezember 2013 10:38:16 UTC+1 schrieb Toby Kurien:

With regards to the synchronized keyword, it's in any case better to use ReentrantLock
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantLock.html

Not really. The JVM performs additional checks and optimizations for "synchronized" blocks that it currently does not provide for ReentrantLocks. But of course nothing stops you from having a @ReentrantLocked annotation =) I just think that @Synchronized should do exactly what it says to avoid confusion.

[Sebastien Diot]

On Tuesday, December 10, 2013 10:38:16 AM UTC+1, Toby Kurien wrote:

With regards to the synchronized keyword, it's in any case better to use ReentrantLock
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantLock.html

As I think I mentioned before (in another post?) Locks are useless to me, because I'm writing code that should be compatible with GWT (GWT quietly ignores the synchronize keyword, but does not provide support for Locks).