Hacker News Reader

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

It appears to be common Hackernewserthink that "productivity" equals "the ability to write code as fast as possible". Beyond the first few weeks of coding, you'll spend much more time reading code and refactoring it.

What Xtend offers is an object model and type system that anyone with Java experience can understand right away, but with significantly more readability. This means better maintainability, which means a significant productivity increase once you're past the "hack away, guys!" stadium.

Coffeescript has exactly the same major advantage over JavaScript. The point is that because CoffeeScript/Xtend so closely mimic their target language, there are no leaky abstractions, so no thinking-in-two-worlds headaches. Yet, the code becomes significantly more readable, which matters.

These developments really are major. There's a reason so many more people use CoffeeScript than, say, ClojureScript or GWT. The only reason why the same wouldn't happen with Xtend in the Java world is non-technical: too many Java shops are conservative and afraid of change, even change as low-barrier as Xtend.

They should've called it "Coffee", though.

> It appears to be common Hackernewserthink that "productivity" equals "the ability to write code as fast as possible". Beyond the first few weeks of coding, you'll spend much more time reading code and refactoring it.

And even more time thinking.

This is one of the reasons I never understood the obsession many people have with vim/emacs/whatever shortcuts and the like, for me they are distractions from what is really important: thinking about what code does and what it should do.

Fun fact: Ken Thompson doesn't touch-type, and a couple other amazing hackers I know are the same. I suspect this might even be a benefit as it encourages them even more to think before they type.

These things are a form of "premature optimization," which I think anyone can be misguided into, but which younger/less experienced programmers are particularly prone to, because they naturally tend to have uneven skill development, so they'll try to build from strengths before branching out.

Premature optimization of typing = complex text editor

Premature optimization of debugging = excessive unit tests or formalism

Premature optimization of product = coding features without feedback

Having typed since I was 5, I think while typing, and going back and forth in code is the same as thinking for me. I'd expect that most of these amazing hackers are from the era where they wouldn't see a keyboard until being 16 or 18.

I'm not a vim/emacs shortcut freak, but I do appreciate environments that don't make me use a mouse.

And more specifically: It appears to be common Hackernewserthink that "productivity" equals "the ability to type code as fast as possible".

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

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

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

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.

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.

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.

I am confused.

Update: I didnt downvote you btw.

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.

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.

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

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

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.

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

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.

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!

HN is the wrong forum to discuss this. Many people here are not the target audience who don't use Java and have a preconceived dim view of it.

(I'm expecting downvotes but whatever.)

What's the right forum for this, then?

You're right. HN is predominantly fashion lead hipsters (No offense).