Earlier quoted context omitted.
The fact that Xtend can be easily translated to Java source code is a big sign that it probably won't have any dramatic impact on your productivity I do not believe that there is any evidence for this statement. Translating ARM assembly language into opcodes is orders of magnitudes easier than translating Xtend into Java, yet I would argue that even that had a dramatic impact on my productivity back when I was doing…
The evidence for this statement best comes from a research paper* that attempts to formalize language expressibility . According to their formalization, language features are classified as macro expressible if they can be implemented in terms of local syntax transformations of other language features. The paper shows that expressivity, power, and conciseness come the most from those features that are not macro expres…
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.