5 ms·

I'm pretty disappointed in the discussion that has gone here. There's been so much argument over things that don't matter much in the end, like whether or not o

by sreque 15y ago

I'm pretty disappointed in the discussion that has gone here. There's been so much argument over things that don't matter much in the end, like whether or not optional semicolons and parenthesis are a good thing. These things are so superficial! It makes me believe that few people appreciate what actually makes a language good or bad. 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 think the comparison that has been made between Xtend and Coffeescript is most accurate. Xtend will likely be more pleasant to work in than Java, but it won't be a game changer in terms of what you can accomplish with it. Still many people are happy with Coffeescript, and if Xtend does thing right many people might be happy with it as well. And, I'm pretty sure David Pollak is the only Scala evangelist who is worried Scala won't or shouldn't overtake Java. Everyone else seems to be committed to making Scala a better and better out-of-the-box experience, and there continues to be initiatives and commercial investment in improving things like IDE support, documentation, coding standards, training opportunities, and more.

buff-a 15y ago
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 15y ago
  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
  - buff-a 15y ago
    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 15y ago
      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 15y ago
        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.
        15y ago
- Dessimat0r 15y ago
  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!
skrebbel 15y ago
> 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.
- luriel 15y ago
  > 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.
  - chipsy 15y ago
    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
ww520 15y ago
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.)
- maximusprime 15y ago
  You're right. HN is predominantly fashion lead hipsters (No offense).
- morsch 15y ago
  What's the right forum for this, then?

by sreque 15y ago

buff-a 15y ago

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 15y ago
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
- buff-a 15y ago
  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 15y ago
    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 15y ago
      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.
      - 15y ago
Dessimat0r 15y ago
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!

skrebbel 15y ago

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

luriel 15y ago
> 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.
- chipsy 15y ago
  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

ww520 15y ago

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

maximusprime 15y ago
You're right. HN is predominantly fashion lead hipsters (No offense).
morsch 15y ago
What's the right forum for this, then?