Eclipse launches new language to cut down Java boilerplate

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#111

Post by buff-a » Sat, Nov 05, 2011, 4:03 AM UTC

sreque wrote: post #108

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…

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

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#112

Post by Periodic » Sat, Nov 05, 2011, 4:08 AM UTC

meric wrote: post #109

willurd wrote: post #100

Earlier quoted context omitted.

You left a type in there! greetABunchOfPeople people people do _ sayHello println

While we're at it, let's switch to haskell (delete the unnecessary people argument): greetABunchOfPeople = mapM_ (putStrLn . sayHello) Explanation: mapM_ is a function that takes two arguments. mapM_ lambda list It calls lambda on each element on list. In the greetABunchOfPeople definition, notice we only gave mapM_ 1 argument instead of 2. That means greetABunchOfPeople would have to take an extra argument for the c…

You beat me to it.

What I love about the Haskell version is it says only exactly what needs to be said.

sayHello - get the hello message for something. putStrLn - send something to stdout mapM_ - Do these things in sequence, I don't care about the result.

Together they say take a list of people, get their greeting strings and print them to stdout in order. It's hard to say it more succinctly without making things confusingly implicit.

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#113

Post by LeafStorm » Sat, Nov 05, 2011, 4:16 AM UTC

As far as I can tell it's only shipped as an Eclipse plugin. Are there any plans for a standalone Xtend compiler that doesn't depend on Eclipse?

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#114

Post by 6ren » Sat, Nov 05, 2011, 4:16 AM UTC

"multi-line string literals" are very useful, because they enable you to create DSLs that are easy to use. As in the example, you can have HTML; or XML; or make up any language you want.

Of course, it doesn't help you implement it (you'll have to parse the string yourself); but it makes it usable. A downside is that it makes that code hard to understand for developers unfamiliar with the specific DSL.

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#115

Post by Periodic » Sat, Nov 05, 2011, 4:17 AM UTC

Roybatty wrote: post #55

eitland wrote: post #39

Earlier quoted context omitted.

The biggest issues are less about syntax and more about having to restart containers etc again and again. But everyone except Play! and a few others seems to be jumping the new syntax bandwagon. Being a php/python/Java developer I'm afraid I'd trade all improvements after generics for a no restart required jvm

No, no, no. Our fancy, schmancy IDEs can produce the code for us, but we still have to read the Java boilerplate.

Reading Java can be the hardest part about working with it.

When working with Haskell and discussing why you would want to use let vs. where or if vs. guards, Bryan O'Sullivan explained it to me by borrowing a term from journalism: Don't bury the lead.

You want to put what the function does right at the top. The first thing it should tell you is that it prints hello for each person in a list. Then you can put the details of how that's done in definitions below. It allows you to write functions so that they are easy to read and so that the structure of the semantics are separate from the implementation details and the requirements of the system.

Java's rigid boilerplate has always stood in the way. It would be like if every newspaper article had to list all of its sources, with full names and titles at the start of an article and then had to list events in chronological order. They would be mind-numbing to read. Sometimes I just want a good juicy sound byte right in the first sentence so I know why I should be interested.

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#116

Post by sreque » Sat, Nov 05, 2011, 4:34 AM UTC

buff-a wrote: post #111

sreque wrote: post #108

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…

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…

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

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#117

Post by naveen99 » Sat, Nov 05, 2011, 4:42 AM UTC

hopeless wrote: post #5

Oh, it looks like Xtend is to Java as Coffeescript is to Javascript. Although I'm sceptical about it compiling to Java source. Java seems to be going through a period of experimentation, and alternative Java-like and JVM languages. Interesting times.

Legal JavaScript is legal coffeescript.

Is legal java legal xtend ?

Can we expect something like http://js2coffee.org

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#118

Post by buff-a » Sat, Nov 05, 2011, 4:45 AM UTC

sreque wrote: post #116

buff-a wrote: post #111

Earlier quoted context omitted.

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…

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 expres…

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.

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#119

Post by linuxhansl » Sat, Nov 05, 2011, 4:53 AM UTC

Meh. I don't understand what is so bad about Java.

Yes, there's boilerplate, which can addressed with the right development tools.

New languages are a good thing. But a language whose sole purpose is to remove boilerplate from Java, does not really get us anywhere.

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#120

Post by vorg » Sat, Nov 05, 2011, 5:11 AM UTC

bartonfink wrote: post #9

This reminds me quite a bit of Groovy, just with a different compiler back end (outputting Java source instead of bytecode). However, this makes me wonder what the point is. Groovy is more-or-less source compatible with Java already (a valid Java program is also a valid Groovy program), so I'm not sure what Extend brings to the table.

> a valid Java program is also a valid Groovy program), so I'm not sure what Extend brings to the table.

Groovy is dynamically typed, not statically typed. Though a month ago Springsource/EMC hired someone to build a static type checker (called Grumpy) for Groovy (http://www.jroller.com/melix/entry/groovy_static_type_checke...) with the usual solicit for free labor by spinning the "open source" tale.

Presumably they heard about Xtend from the same place Jboss/Redhat and Jetbrains did. Hence the recent avalanche of announcements regarding Ceylon, Kotlin, and Grumpy.