[bdj]

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).

[buff-a]

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.

I am confused.

Update: I didnt downvote you btw.

[skrebbel]

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.

I love it.

[buff-a]

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.

[scott_s]

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.

[buff-a]

It doesn't have any new abstractions except for those two really useful ones. Oh, ok, but it other than those it doesn't have any new ones. =)

[skrebbel]

Eh. I was arguing the direct opposite. I have the feeling that you're just looking to pick a fight.

[bdj]

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.

[buff-a]

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.

[bdj]

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.