You misunderstand what a local syntax transformation is. A syntax transformation is just a function that takes syntax as input and returns syntax as output. The function can be arbitrarily complex, even "inferring" things from the input syntax.
The key point is whether the transform is local or global. An example of a global transform is turning a program into continuation-passing style because it must change every function definition and function call in the program.
The transforms that Xtend is doing appear to be local. Converting closures to anonymous inner classes is a local transformation. Their "type inference" isn't real whole-program type inference, it just saves keystrokes within certain expressions. The fact that they can show you the underlying Java code that each new feature turns into indicates that the transforms are local.
Also, these types of transformations really are trivial in languages with full-featured macro systems (like most LISP dialects).
The referenced paper is way over my head, so I'll just say where I'm having difficulty and perhaps you can help me out.
Java doesn't have closures. Xtend does. Closures seem to me to satisfy the paper's definition of providing greater expressibility. Certainly, I've done a lot of C# and Java, and having closures in C# has greatly influenced how I write code.
And yet closures appear to be what you claim is a local syntax transform, and therefor can not add any expressibility to the language.
Java's anonymous inner classes basically work like closures, except that they require that you mark some variables as final and that you have to write a lot of boilerplate. My underbelly feeling is that xtend's closures merely compile to those.
Often, such closures are enough. E.g. with Google Guava's predicates and filter/map methods, you can do with Java (guava + anonymous inner classes) what LINQ enables in C# (System.Linq + lambda expressions). The Java version has a lot more line noise than the C# version, however, which is what Xtend fixes.
And C++ classes merely compile to C methods with mangled names that also take a pointer to a C struct, the first member of which is a pointer to an array of such functions, and whose remaining members are the fields.
If you (or GP) are going to argue that C++ is no more productive than C simply because cfront turns C++ into C, then I think theory has gotten in the way of reality.
I think the key difference is if the language feature automates a kind of abstraction that was manual in the other language. For example, one can write object-oriented programs in C, but you have to do it all yourself. And C++ programs can, as you pointed out, be translated to equivalent C programs. But classes and objects in C++ are language level abstractions that don't exist in C. In that regard, I agree with you: if you want to do OO programming, one can be more productive in C++ than C.
I have read much detail about Extend, but to me, the key question becomes: does it have language level abstractions that Java does not? I think closures and anonymous functions qualify, but I don't know if they're enough to make that much of a difference.
But what I've seen of Extend, with the exception of closures and anonymous functions, it doesn't actually have any new abstractions. It just cleans up the syntax.
Closures are code+data and objects are also code+data, so adding closures to a language with an object system does not increase expressibility.
The main difference is that with closures you write the code and the data part (the environment) is captured implicitly, whereas with objects, both the code and data are explicit. This makes it possible to convert a closure into an object, and an object into a closure, without having to change the whole program.
It is a little more difficult to go from closures to objects because you have to find the free variables and make them explicit, but it still isn't a global transformation. If you want to see how to implement objects with closures, check out SICP.
It's all code plus data. I can implement any java, C#, Xtend feature in C or assembly language, but by your argument that makes C# no more expressive then C.
If this is your argument, then it would appear that your argument is that the entire class of imperative languages are a waste of time and we should all be using lisp or scala.
Back in the real world, I find C# to be more productive than C, because I am able to express myself more succinctly. Xtend seems to do that for java. In the imperative world, your definition of expressibility is insufficient to determine increases in productivity.
The question isn't whether or not feature A can be implemented in language X, it is whether or not it has to be implemented as a local or global transformation. This is what the paper cited above defines as expressibility: adding a feature that requires a global transformation increases expressibility.
I made no claims about whether or not more or less expressibility is a good thing or how it relates to productivity. Nothing in my responses has anything to do with whether or not functional or imperative styles are better in terms of productivity or maintainability. In fact, by the definition in the paper, adding imperative features to a functional language increases expressibility. Also, adding goto to a language increases expressibility, so it is not a metric that is solely related to maintainability and productivity.
I am not arguing that Xtend is a bad idea at all, in fact I think it's a great idea. The whole reason people like languages with powerful macro systems is that they can implement features that Xtend gives to Java in the language itself, rather than having to wait for a new language implementation.
This is not a meaningless comparison; it points out one of the main deficiencies of java: lack of first-class functions. The closest you can come is using anonymous inner classes, which is kind of kludgy.
This is sad because this is one of the only technologies my mom is comfortable with using. She uses this service on almost a daily basis. When I called her and told her about this story, she asked if there was some way to call them up and complain about it. I know Google is notorious for not having very good customer service, but does anyone know if there is a number she could call?
Google is (believe it or not) working on being more accessible to customers, but no, right now, there isn't a number she can call. It's sad that people like your mom are disappointed, and there are plenty more like her out there, but calling up isn't going to change anything :(
Intellij has a few features that I would have a hard time living without. Code inspection is probably the number one feature that is pretty amazing. You can configure it to check everything from warning about null pointers to unused variables to questionable practices (like an assignment in a conditional). When you have a green light, you can be reasonably sure that the code is clean from most basic problems. The autocomplete is the best I've seen in any IDE, and it allows matches on CamelCase by just typing the capital letters and brings up choices based on type inference. The version control integration is also pretty amazing; I think they could sell the change management and merging portion as a stand alone tool that would do really well on its own. Overall, IntelliJ lets me get into a flow with programming by making a lot of the warts of Java melt away. Sometimes it feels like it's almost writing the code for you and you are just giving it some direction. I know that some of these features have been implemented in Eclipse, but the way they all integrate so seamlessly makes IntelliJ a fun environment to code in. I miss these features in other languages that don't have an advanced IDE.
"I know that some of these features have been implemented in Eclipse, but the way they all integrate so seamlessly makes IntelliJ"
Sounds as if it's just what you are used to, not that one is better than the other. Back then when I worked with Eclipse, it did not seem full of seams, either.
Edit: In case it wasn't obvious, I meant an IDE that you're just used to using, and that you think it's perfectly alright because you're not aware of better options.
I've got some anecdotal evidence to support this, so if you disagree, let's hear yours.
Have you really tried IDEA, and did you really not think it was better than Eclipse?
"Have you really tried IDEA, and did you really not think it was better than Eclipse?"
Yes and yes I did think it was better than Eclipse but I did not think it was better than Netbeans since 6.5 and on. I think the problem with IDEA is they are beginning to have trouble keeping up with the latest trends in the industry given that fact that a lot of those trends are coming out of open source it is natural that the open source IDE's will implement tooling before there closed source competitors.
That being said IDEA always felt more "bolted together" and consistent than Eclipse but the trade-off was always that they did not have tooling for some of the things eclipse did, so personally I would have to jump between the two.
Since Netbeans 6.5 and now 6.7 I have moved away from both as, for me, it has both covered well. It is polished as if it where build less by community and more by a driving vision. It also has a large community following implementing new tooling for the latest and greatest. Take the JavaScript tool-kits for example, Netbeans is the only IDE short of Aptana that I have seen, that implements code completion jsdoc inspection, code navigation, debugging, trace from JavaScript client, through server to database, etc. etc. for all of the major JS frameworks.
Anyway, long story short, IDEA is competing in a space that is becoming increasingly difficult to remain closed source. Especially when some of it's open-source competitors have caught up with it in it's mainstay, efficiency and usability.
I haven't tried IDEA because I wasn't willing to pay for it. Also I wonder if the plugin scene for IDEA is as alive as it is for Eclipse? Proprietary software always seems like a dead end, so I prefer not to invest time in learning it.
The key point is whether the transform is local or global. An example of a global transform is turning a program into continuation-passing style because it must change every function definition and function call in the program.
The transforms that Xtend is doing appear to be local. Converting closures to anonymous inner classes is a local transformation. Their "type inference" isn't real whole-program type inference, it just saves keystrokes within certain expressions. The fact that they can show you the underlying Java code that each new feature turns into indicates that the transforms are local.
Also, these types of transformations really are trivial in languages with full-featured macro systems (like most LISP dialects).