I do not accept your implicit claim that a language must be more expressive, powerful, or concise to be more productive.

As a counter-argument for the expressive claim, consider a language that required one to prefix each line with the number of non-blank characters it contains. I am fairly sure I would be more productive using a preprocessor that computed those prefixes for me. Real world examples of the same are the abolishment of line numbers in Basic, assemblers that know about structure offsets, the C preprocessor, and type inference. Each, I think, helped increase productivity.

'Power' cannot be a factor at all, as basicly all programming language are equally powerful; there are no degrees of Turing completeness.

That leaves conciseness. I do not think that claim would need debunking, but for completeness: if that helped productivity, everybody would use single-character variable and function names (should mostly be possible in languages that allow Unicode source code), and program in APL or perl.

This is the key concept, and I disagree with you that this is all Xtend is. Its why I think you are wrong. Specifically, the Xtend transformation is adding information to the java code it generates that it must infer from the Xtend source code. It is precisely not a local syntax transformation.

I think you are assuming that because they make it look easy, that all it is is another macro language with, as you say, local syntax transformations.

That aside (since I agree that most of what they're doing appears to be fairly local, at the moment), what are the features that you miss in Java anyways, as compared to something like Ruby or Python, once you add closures and a bit of syntax sugar to cut out boilerplate? Past that, I can't think of much that people actually use day-to-day (and no, callcc doesn't count) in Ruby or Python that's not already possible in Java, albeit with a little more line noise. Can you?

When I look at code across many languages, the thing that makes Java code stand out as particularly clumsy is that it forces a lot of local verbosity, and that functional programming is very clumsy due to the lack of closures (though it's possible if you're willing to swallow your pride and endure some pain).