[buff-a]

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 such things. If Xtend introduces proper closures just that right there will improve productivity.

However, if I were to accept your premise that easy translation implies little value added, then I would have to point out how wonderful it is that we live in a time where we regard writing a parser for a language like Xtend and the requisite bits of goo to spit out java is considered "easy".

[sreque]

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 expressible. Yet, none of Xtends features seem to be in that category.

Since most languages don't have macros or compiler plugin frameworks, there can still be great value in adding macro expressible features, but, as I said in my previous post, these are less likely to be game changers in terms of productivity. These are the kinds of features that IDEs can make up for with templates and code generators. As an example, an anonymous class might be bulky, but it essentially provides the same feature set as a closure and the IDE is good at writing most of the boilerplate for you.

*see www.ccs.neu.edu/scheme/pubs/scp91-felleisen.ps.gz

[Someone]

"The paper shows that expressivity, power, and conciseness come the most from those features…"

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.

[ekabanov]

There are no real Turing-complete languages, as Turing-completeness requires infinite hardware. And certainly there are degrees of incompleteness, expressed by which programs run out of memory faster.

[buff-a]

local syntax transformations

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.

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

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

[bermanoid]

First, the fact that this language is coming from the Eclipse team suggests to me that they are probably not limited to macro transformations, at least at a fundamental level. The main reason Java folks like Eclipse is that it has a global understanding of Java code (this is why plugins for text editors tend to flat out suck compared to real Java IDEs, they are mostly dealing with local information), and I'd imagine that people working on an IDE that made non-local code comprehension a core focus of the product would make sure they're able to extract that information fairly easily from a language that they designed themselves.

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

[celer]

The single thing I would say Java is missing, from the perspective of a beginner, is the ability to change code while running it. Eval and Exec are useful functions, and there is no way to replicate them in Java.

Lists in Java are an unholy pain that redefine cruelty in an entirely new way. You can't make a list, to the best of my knowledge, that accepts arbitrary inputs. Does the utter lack of a slice operator count for the addition of multiple lines of code to replace what is normally three or four characters?

Please, tell me how. This is an honest question. I have been learning Java since school started, and I miss my functional techniques.

[Dessimat0r]

Another issue is that UI tools like WindowBuilder Pro won't work well with the generated Java code which will likely end up getting overwritten by the Xtend builder. Mmm. But it wouldn't have worked anyway without the conversion!