
Eclipse launches new language to cut down Java boilerplate - Extend - dnene
http://www.eclipse.org/Xtext/xtend/
======
sreque
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.

~~~
skrebbel
> _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
> 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
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

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

~~~
lemming
One of the nice things about compiling to Java source is that it allows you
use it with GWT. The only downside that I can see is that there might be
constructs that you can't express in Java that you would want in a new
language (note that you're fine with ones that you can technically express in
Java but are just ugly, like closures). There are probably not very many of
them, though.

~~~
DanielRibeiro
Well, scala can be used with gwt: <https://github.com/scalagwt>

It was documented on scala, page, but now you have to use the google cache to
see this:
[http://webcache.googleusercontent.com/search?q=cache:wqqu7uQ...](http://webcache.googleusercontent.com/search?q=cache:wqqu7uQ3v5cJ:www.scala-
lang.org/node/11397+&cd=1&hl=en&ct=clnk)

~~~
CarlSmotricz
Exciting! Thanks for the link.

------
dustingetz
scala's own evangelists are worried that scala won't overtake java: "...Scala
(the language, the tool-chain, the ecosystem, nothing about Scala) is not
mature enough to be a Java replacement and barring an order of magnitude or
two more investment into Scala commercialization, I don't see Scala becoming a
Java replacement"[1]. this is despite seeing twitter and foursquare adopt
scala at scale. and Scala's team, Odersky et al, are _credible_. they've
already been through the extend java approach[2]. it didn't work. i see no
reason xtend will be any different.

    
    
      [1] http://www.infoq.com/articles/barriers-to-scala-adoption
      [2] http://www.artima.com/scalazine/articles/origins_of_scala.html
    

anyway, i think the biggest problems with java are lack of first class
functions, and no tools to enforce or nudge towards referential transparency.
If Xtend helps with this, their page sucks because i skimmed it and i can't
tell. verbosity and syntactic sugar seems to be the focus and incremental
improvements typically aren't worth the inherent risk of changing pieces of
our stack.

edit: xtend does seem to have first class functions per below, so my argument
is weakened. i'll leave this post for discussion though since its going
through some pretty wild vote swings.

    
    
      val predicate = [ Person person | "Hans" == person.name ]
      persons.filter(predicate)

~~~
weego
My understanding is that the primary group of Scala evangelists are aiming for
Scala adoption through promotion direct to enterprises as a blanket solution
to every market, without any real effort to promote Scala at grass roots or
toolchain levels.

Correctly some other prominent Scala community members are concerned that this
approach can easily lead to high profile failures in Scala adoption and that
is a death blow when a language/platform is in infancy and that they should
narrow their initial promotion to a few key markets and grow from there.

------
Lewisham
This basically looks like Kotlin, except it explicitly compiles down to Java.

I'm not sure how I feel about this. Pre-Kotlin, I would have thought "hey,
neat", but now it seems like we're on the verge of a number of half-supported
half-hearted attempts at being Java.next, each with their own pros and cons. I
wish that IDEA and Eclipse could have worked together on this.

~~~
squidsoup
It's a pity everyone gets so worked up over trivial things like parens -
Clojure is a beautiful language that absolutely deserves to be the next big
language on the JVM. Yes, it offers a different programming paradigm from
Java, but perhaps to make any genuine headway in the future we need a clean
break from Object Orientation and it's muddled conflation of identity and
state.

~~~
hello_moto
Are you absolutely sure that Clojure can fit all problem domains? Clojure
might be great for MapReduce type of programming. Does it fit a typical
Accounting, CRM, Claim management (those kind of business-y app) software
projects?

~~~
moomin
Actually, I really am sure Clojure will fit in all of those problem domains.
Indeed, I'm pretty sure that if you experienced a well-written Clojure
accounting app, you'd wonder why people bothered with Java.

~~~
hello_moto
Would like to see the code if you have the example. Would be a very
interesting case-study as to why Functional fits such problem domain as
opposed to OOP because this would open a new perspective.

Please share more. I'm interested. (Let me know if you can only share your
experience via private channels).

~~~
moomin
Sadly, I can't share any code, but here's my basic observations: First,
calling a standard Java object from Clojure is extremely painless. It's a bit
more complex if you're dealing with listeners, but in general terms a java
object is a java object without very much getting in the way. This means that
all of your favourite GUI libraries are usable without modification.

Second, as Carl pointed out, Clojure does have state, it's just tightly
controlled. So tightly controlled that multi-threaded programming is much
easier. There's some things that I'd like on top of what it does, but it's
very powerful and useful.

Thirdly, I'm not denying that thinking functionally takes a while, but as you
develop the skill, it's amazing how many things actually look pretty
stateless. I've met actuaries who use F# for all of their calculations.
Equally, converting game state to a 3d scene graph is a pretty stateless
process (although I've yet to meet anyone who's actually getting paid to do
functional game programming).

Hope that is interesting. Will be glad to share more.

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

~~~
liquidcool
I agree, I don't see a reason to switch from Groovy. I don't see the Scala or
Clojure people switching, either. But even if you're just trying to convince
Java developers, Groovy's ecosystem (including Grails) is hard to beat.

And actually, I'm using Groovy++ (<http://code.google.com/p/groovypptest/>),
which addresses the concerns about static typing, inference, and performance,
all for the cost of an extra jar. It's really surprising how few people - even
Groovy programmers - have heard of this. I think it really ought to be
included in the core language.

~~~
vorg
>I don't see a reason to switch from Groovy

> Groovy's ecosystem (including Grails) is hard to beat

Are you part of Groovy's echo system too?

------
phzbOx
So, "Extend is for the Java Programmer". I'm curious to see how this will turn
out as there are some pretty cool features in this language. (Particularly the
multiple dispatch, closures and type inference). However, any Java programmers
could have made the switch to Clojure or Scala to keep working with the JVM.
But, Extend is different in that it generates Java code instead of JVM. So,
I'm wondering who will use that.

\- Java programmers who are still stuck with old version: Even though they'd
dream about using this, I'm guessing that won't compile to java 1.4/1.5..
right?

\- Java programmers who already switched to high level language on top of jvm
(Scala, clojure, etc.): Maybe the few who are still with Eclipse would switch
back.. but I guess the majority of programmers in this scenario wouldn't want
to switch.

\- Java programmers who refuse, for various reasons, to learn newer
languages/tools: Since it's still Java.. and still in Eclipse, it might be
easier for them to give it a try? But then, if they refused to switch to newer
language, it might be surprising to see them switch to Extend.

I'm a bit puzzled (as you can see). Personally, if I have to use the jvm, I'd
go with clojure all the way.

~~~
melling
Java 1.6 is 5 years old. If you're the kind of company that couldn't upgrade
to it in the last 5 years, it's probably too big of a leap to adopt this.

~~~
dustingetz

      > If you're the kind of company that couldn't upgrade to Java 1.6 in 5 years
    

it doesn't always work like that. imagine a very rich customer who has all
sorts of proprietary customizations to all of their software investments.
millions of LOC. nobody's gonna port that shit off of java 1.5, and they told
ya to deploy in their existing server environment, and ya do it because, well,
they're rich.

~~~
spullara
There is no porting to be done between 5 and 6.

------
devs1010
Eclipse is painful to use, just switching to using IntelliJ Idea IDE I have
felt a lot more productive. I still have to use both since my company's
"official" IDE is Eclipse and if I'm working on a problem where another
developer might be looking at something with me I have to use it or they'll
get really uncomfortable. The auto-completion in IntelliJ and better
responsiveness of the UI make it a much better expiernece IMO. I really think
one of the main problems with Java IS Eclipse, if more Java dev's used a
better IDE I can't help but wonder if things like this wouldn't be thought of
as being as necessary

~~~
random42
I _just_ started on Java on eclipse, after 4 years of _IDE-less_ coding in
python.

Care to tell me what you find better in IntelliJ, as compared to eclipse, so
that I dont waste a lot of my time with Eclipse? :-)

~~~
moss
* There are memorable keyboard shortcuts for everything. * It can generate comparatively more code for you. * It's faster, though I fear it's working on losing this advantage. * The autocomplete is smarter, and has a few different options.

I started using IntelliJ a few years ago, when I came onto a Java project
after several years using vim and Python, and I'm convinced it made the
transition a lot less painful.

The difference between IntelliJ and Eclipse may be smaller than it feels to me
now--IntelliJ is what I'm used to, after all, so using Eclipse involves
adjusting to a subtly different interface--but I'd still say it's worth a try.
There's a free version, so there's not really anything to lose.

~~~
devs1010
Eclipse crashes on me or freezes up frequently despite using a quad-core
brand-new laptop with 8gb memory. The UI frequently becomes unresponsive.
Anything to do with IO such as opening files, having maven pull in a bunch of
files, etc is horribly slow and usually causes the app to freeze.

As far as I know it doesn't offer variable suggestion, in IntelliJ you just
type the first letter or 2 and it immediately suggests any variables you have
in scope, I find this invaluable as it really speeds up writing code
sometimes. Overall, I find it simpler whereas Eclipse is just kind of a free-
for all where you need to make use of a patchwork of plugins to be successful.
IntelliJ is written by one company so I just always get the feeling it has a
better "engine" underneath it.

Half the developers on my team curse Eclipse and say they hate it but none
have switched to using another IDE except me, the others are too set in their
ways, I get the feeling its firmly embedded amongst a certain generation of
Java dev's but if you're just starting out (I'm also pretty young relatively
speaking) I'd recommend considering using another IDE.

~~~
kodeninja
Eclipse does offer variable suggestion/completion using Ctrl+Space. Works for
class names, variables, method names etc. Camel Case search is another nice
feature. I personally use SpringSource STS (especially for the Groovy
support). And btw, IDEA freezes up as much as Eclipse does. It's more of a
problem with desktop Java applications, than with a specific IDE.

~~~
devs1010
I've never had IDEA freeze on me. Eclipse may offer those (I wasn't aware of
it) but you would have to tinker around to configure it, I really prefer
simplicity to a mountain of configuration to get it working the way I want.
Eclipse is more of a platform, its great for some things since companies have
built plugins for all sorts of things (like the Drools visual editor, for
example), its fine for this sort of thing but as a regular code editor I find
I prefer to use something that is more simplified and limited, not something
that is essentially trying to be a platform.

------
mbreese
You know that when even Eclipse is coming out with an updated JVM/Java.next
language that Java proper has some major issues.

~~~
eitland
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

~~~
akeefer
Depending on why you're restarting your VM, you may want to check out the
DCEVM: <http://java.net/projects/dcevm>

It lets you do arbitrary hotswapping of code, rather than only swapping method
bodies. Not appropriate for production at this point, but you can install it
on top of any Java 6 version prior to update 26 (not sure about Java 7); it's
pretty useful for doing rapid iterations during development of large-scale
server apps or swing applications.

~~~
ww520
Does anyone have the documentation or tutorial for DCEVM? I've looked at it
from time to time but never able to figure out how to use it. There's no doc
beside the jar file.

~~~
akeefer
Sorry for the late reply (didn't see the question until now). The DCEVM is
just a patched version of the JVM dll/so file that allows the normal hotswap
mechanism (triggered by JVMTI) to accept arbitrary class changes, rather than
just method body changes. There's no additional mechanism or API, it just
makes the already-existing mechanism for hotswapping better. To install it,
you just run the installer jar and point it to your jdk. To use it, you just
trigger a hotswap as you normally would, which generally means starting your
program in debug mode via an IDE, and having the IDE automatically swap
changes for you as classes change locally. If you want to do hotswapping
without the IDE, that's a bit trickier. Technically, you can write your own
JNI code to directly hook into JVMTI and trigger a hotswap (which is what we
actually do with our development platform at Guidewire), but the easiest way
to do it is generally just to use the debug capabilities of the IDE.

------
ebiester
While it bothers me that it's Yet Another JVM Language when we have too many
anyway, this is exactly what I want from a "blub" language. It adds the
syntactic sugar that I care about, but since it compiles to java rather than
the JVM, I can actually debug it, and stack traces make sense. It has IDE
support.

In my personal projects, I love playing with the newest technology. However,
when I'm in the enterprise, the point of the language is to communicate
effectively to another programmer the intention of the code, because that code
will outlive my time at the company. This looks perfect for that purpose.

------
nyellin
_Parenthesis for method invocations are optional, if the method does not take
any arguments.

obj.compute instead of obj.compute()_

That seems silly. The optional semicolons also irritate me.

\----------------- (Added)

I imagine a committee of Java developers, in a penthouse boardroom at Oracle,
meeting with management to discuss Java's descent into disuse.

"Lets make Java more concise," suggests a senior developer.

"Yes! Lets get rid of the parenthesis like Ruby!"

"And the semicolons like Javascript."

All falls silent. Everyone stares at the programmer.

"But... But..." stammers an important board member. "I thought we needed
those."

"We could make them optional."

"Yeah, we'll be multi-paradimatic like Perl!"

And so Extend was born. A cargo cult at its best.

~~~
rayiner
There is nothing wrong with optional semi-colons. In most cases, the parser
doesn't need them, and the programmer doesn't want to type them. But they're
useful in some cases for disambiguation, especially in a language like Xtend
that doesn't use an explicit return. E.g.

    
    
        foo("bar") ;
        (a + b)
    

The semicolon is necessary for disambiguation in a case like this, but there
is no reason to require the programmer to put in semicolons everywhere. I
think the operator precedence hierarchy and optional parens to override it is
way more complicated, but people seem to deal with it fine.

~~~
politician
"The semicolon is necessary for disambiguation in a case like this..."

 _This_ is why semicolons should be mandatory or illegal. The whole "optional
semicolon" thing is a mis-feature designed by language committees that can't
make a decision. One's codebase becomes a mismash of lines with and lines
without semicolons, sprinkled in as magic to make the compiler happy.

There are plenty of interesting language features which are useful -- support
for "optional semicolons" isn't one of them. The feature needs to die, and
people should just choose to use a language that suits their need to type --
or not type -- a ';'.

~~~
rayiner
We should also use a fully-parenthesized prefix syntax so we don't get a
mishmash of lines with and without parentheses used to override operator
precedence!

I agree Javascript's "automatic semicolon insertion" is a terrible feature,
but largely because the description is so hard to understand that programmers
don't know when the semicolon is required.

In an expression-oriented language, like Xtend seems to be, the rule for when
you need a semicolon is simple. The parser makes the longest legal expression
it can, if that's not what you mean, then add a semicolon. It's no harder to
understand than the lexer equivalent (the lexer makes the longest token you
can, if you want to resolve the ambiguity insert a space), or the operator
precedence rule (the parser will interpret infix operations using this
precedence table, if that isn't what you mean use parentheses).

Matlab, for example, doesn't require commas to separate list elements, and
doesn't require but allows semicolons at the end of lines, and nobody
complains.

------
rapind
I wish they'd taken it just a little further and made surrounding brackets
optional (using indentation instead). I.e.

    
    
      def greetABunchOfPeople(List<String> people)
        people.forEach
          println(sayHello)

~~~
im3w1l
Further!

    
    
      greetABunchOfPeople List<String> people
        pers:people
          println pers.sayHello

~~~
masklinn
You still have a dot in there!

    
    
        greetABunchOfPeople List<String> people
            people do
                _ sayHello println

~~~
willurd
You left a type in there!

    
    
        greetABunchOfPeople people
            people do
                _ sayHello println

~~~
meric
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 call to execute.

    
    
      greetABunchOfPeople $MISSING$ = mapM_ (putStrLn . sayHello) $MISSING$

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

------
itsnotvalid
I don't know, but, often get irriated by the usage of "closures" when it means
"anonymous function/expression".

    
    
      > The term closure is often mistakenly used to mean anonymous function. This is probably because most languages implementing anonymous functions allow them to form closures and programmers are usually introduced to both concepts at the same time. An anonymous function can be seen as a function literal, while a closure is a function value. These are, however, distinct concepts. A closure retains a reference to the environment at the time it was created (for example, to the current value of a local variable in the enclosing scope) while a generic anonymous function need not do this.

~~~
groovy2shoes
You don't have to assume that they actually mean anonymous functions. There's
no real reason why the Xtend compiler couldn't translate closures to Java
objects.

~~~
itsnotvalid
But by closure I usually refer to the definition of some Lisp books:

    
    
      >> a closure is a collection of closed-over variables retained by a function.
    

I don't really dig deep for what the constructs would produce in memory, but
they should be some lambda expression.

------
discreteevent
Check out xtext which this is based on. Is even more interesting: Define a
grammar and it will generate an editor with code completion etc. For a full
programming language (as opposed to a small DSL) its important to be able to
"debug at the level of the abstraction" as Dave Thomas (not pragprog Dave)
says. This looks like it generates code, so you can't do that.

------
haldean
What is Xtend supposed to provide that Scala doesn't already provide? It looks
like their setting out to solve a subset of the problems that Scala deals with
already.

~~~
theshadow
Unlike Scala it compiles down to Java. Depending upon how readable and sane
the generated code is, I could see people working in organizations where Java
is mandated write code in Xtend and then commit the generated Java code or use
the generated code as base for code that get committed to official channels.
Although I'm skeptical of how readable the Xtend generated Java is.

~~~
lukejduncan
Doing so would mean it would need to be super friendly going the other
direction. It'd be really annoying working in one language, compiling to java,
having someone modify that java, and then needing to read and work through
everything in java now.

------
coryfoo
First thing I thought when I read the headline: "Oh boy, half ass Kotlin, here
we come".

First thing I thought when I saw the website: "Oooh look, Twitter Bootstrap"

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

~~~
moss
Much of the time, I'd agree. But working on a large system in Java, I
repeatedly see a few places where Java's boilerplate overwhelms the code I
actually care about.

Operations on collections:

    
    
      List<String> result = new ArrayList<String>();
      for (String word : words) {
        result.add(word.toUpperCase());
      }
      return result;
    

Accessor methods:

    
    
      private String name;
    
      public String getName() {
        return name;
      }
    
      public void setName(String name) {
        this.name = name;
      }
    

And arithmetic on user-defined types:

    
    
      new Dollars(15).plus(new Dollars(25)).times(new Percentage(80))
    

This bulky, uninformative, junk code is a real barrier to readability, and
these are just simple examples. Sure, it's possible to work around it, and to
keep the badness contained, but it still means time wasted for anyone who
needs to maintain it.

We started writing some code in Groovy on our large Java project at work a few
months back, and it's been a revelation. Groovy feels like a bit of a hack in
all kinds of ways, but we're still delighted with it, because being able to
say:

    
    
      return words.collect { word -> word.toUpperCase() }
    

or:

    
    
      String name
    

or:

    
    
      (new Dollars(15) + new Dollars(25)) * new Percentage(80)
    

just makes it _so much easier_ to see what's going on at a glance. Maybe if I
were on a different sort of project -- one where I spent less time maintaining
old code, or working with collections of data -- reducing boilerplate would
seem like less of a big deal. As it is, though, it has seriously improved my
quality of life. If Xtend can bring that kind of improvement to more people,
I'm all for it.

~~~
linuxhansl
With a bit of code:

    
    
      public interface Functor<T> {
        T apply(T v);
      }
    
      public class Util {
        public static <T> List<T> collect(List<T> l, Functor<T> f) {
          List<T> result = new ArrayList<T>();
          for (T v : l) {
            result.add(f.apply(v));
          }
          return result;
        }
      }
    

You can write:

    
    
      List<String> l = ...;
      Util.collect(l, new Functor<String>() {public String apply(String v) {return v.toUpperCase();}});
    

Not as concise, but not that horrible either. :)

I never quite liked operator overloading, because of infix notation all
operators need to retain their precedence.

------
typicalrunt
Very cool. One nitpick (unless the video glossed over the details) is that the
double arrows in the video for "personToGreet" looks weird because it's not a
basic key on the keyboard.

~~~
dserodio
No problem, when you hit Ctrl+Space on the Eclipse editor it completes with a
pair (opening and closing) these "chevrons"

~~~
LeafStorm
And in other editors on non-Macs, using the US-International keyboard layout
gets you guillemets (their proper name) with `AltGr-[` and `AltGr-]`. On Macs,
they are `Option-\\` and `Shift-Option-\\` (not quite as good, but still
there).

------
gurkendoktor
On the new switch statement:

> Type guards let you switch (or match) for types, which is much nicer and
> less errorprone than the usual lengthy instanceof-cascades we write in Java.

Ruby can do this too, but it never seemed like a really good idea where I've
seen it. The new switch() is better (equals!!), but this particular use case
seems _so_ out of place in an OO language like Java.

Using «» for interpolation is also a big jump when Eclipse still defaults to
MacRoman. (Or have they changed it recently?)

------
nickand
The reason I never used Java is that every time I tried to learn it I would
get type errors. So in order for my programs to work I needed to constantly
define what type things were. The other big problem I had was whenever I tried
to follow examples they didn't work because there is an arcane system of
importing libraries or knowing some long function name. The language doesn't
seem to have any universal functions. You have to import everything. If this
changes any of that then I might use it. I really like the idea of programs
being able to run on any operating system. Oh one more thing is the eclipse
IDE seems to have so many different set ups and ways to download it how can
you know which is the right one?

~~~
Sandman
1\. Java is a statically typed language so yes, the types need to be defined
and known at compile time. Some people like static typing, others not so much.
If you fall into the second group, there's a whole lot of dinamically typed
languages you can try out.

2\. Java is also object-oriented. This means that, in java, all the functions
are methods of objects. There are no 'universal' functions which are not
attached to objects in any way. Again, some people think that the object-
oriented approach is a good thing which more accurately describes the world we
live in, and some don't [1]. It's up to you to decide whether you think OO is
a good or a bad thing.

3\. Regarding Eclipse.. Go to <http://eclipse.org/downloads/>, choose the
installation which suits you best (if you're going to do some standard java
development, then obviously you'll choose the first installation, 'Eclipse IDE
for Java developers'). If you later wish to develop for other languages (or
write enterprise java apps), no problem, Eclipse is very extensible so you can
always include the appropriate plugin in your current Eclipse installation.

[1] [http://www.google.com/search?q=object-
oriented+programming+s...](http://www.google.com/search?q=object-
oriented+programming+sucks)

------
snorkel
(5 years from today) Extend is too low level ... I think we need another meta
language on top of it.

~~~
ramblerman
what's wrong with that?

~~~
nickand
Exactly. It would be nice if someday someone realized a language shouldn't be
constantly trying to teach the programmer something about computers. The best
language would do as much of the work as possible by having a default for
everything and by assuming as much as can be assumed. The point is not to
reaffirm over and over what a variable is and how it is stored. We should
learn that once in a text book and then get some work done. If you are
designing programming languages for a living then maybe you should be
concerned with that. This is called division of labor.

------
bitwize
Quick, list reasons I should use this over Mirah.

~~~
Roybatty
Because there's like 3 dudes (maybe a half a dude if you think full-time) that
are working on Mirah.

Mirah is cool, but from what I've seen Charlie still has to work on JRuby
fulltime and there's no IDE support.

Jetbrains has pull, and I believe Kotlin will be the language that knocks Java
down finally.

------
vilya
There's an assumption that compiling to Java source will make this easy for
Java developers to transition to, which I believe is completely misguided. If
you edit the generated java source you give up the ability to use Xtend at
that point; if you don't then it's no different to using a language which
compiles directly to jvm bytecodes. Their example of being able to debug
through the generated java sounds like a drawback to me: you have to maintain
two models of the program in your head instead of one. Much easier to debug
through the original source!

I applaud any effort to cut down on the amount of boilerplate required in java
though.

------
bartwe
My favorite features du jour are missing, generics on value types and structs.

------
rbanffy
Operator overload would be nice.

But I don't think declaring variables whose type can be inferred from the
right side of the attribution, semicolons or parentheses for parameterless
methods are the biggest problems with Java.

~~~
ashconnor
Isn't that restricted by the JVM?

~~~
rbanffy
It's syntax. You could simply define a rule that the compiler, when facing
objects that do not natively (as in vanilla Java) support operator X would
have the .operatorX method used instead.

The JVM would never know.

------
spaznode
How can we honestly accept anything coming from the people who gave us
eclipse? What a giant stinky pile of pooh that turned out to be.

I think that the current stewards of the java language are actually going down
the most helpful/likely to succeed path to helping fix java by fixing java.
What a novel f-ing concept. As much as it can be anyway, and despite the
serious reservations of the giant doucheball they inherited with most of
oracle. (despite Larry himself possibly being a pretty cool/legit engineer
himself)

------
limmeau
When I read the title, I hoped they had built a replacement for the tedious
XML declaration of plug-ins, with Commands and Workbench Core Expressions and
all that.

(Example:
[http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclips...](http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fworkbench_cmd_expressions.htm)
)

Am I right that Eclipse Xtend is just not targeted towards extending Eclipse
at all, despite the name?

------
LeafStorm
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?

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

------
Yeroc
I'm surprised there's been no mention of Lombok (<http://projectlombok.org/>)
since the goals seem to be the same. Lombok of course, is not a language but
just a set of annotions and annotation processors to handle the code
generation behind the scenes. Will have to look at this more closely to see
how the two compare...

------
hamrickdavid
Good use of Twitter's css framework, bootstrap. Makes it much easier to launch
a website with a decent UI without too much thought.

~~~
Fingel
I noticed how they literally took the bootstrap front page and changed a few
images and the text. Fast indeed. <http://twitter.github.com/bootstrap/>

------
Sandman
I'm actually kind of worried about what the generated Java code will look
like. From what I can see from the greeter example, it's.. well, not very
pretty. It certainly looks nothing like what one would normally write if one
was writing pure Java code. Imagine having to maintain that.

~~~
ramblerman
I 'm pretty sure you would maintain the extend code. Otherwise your doing it
wrong :P

~~~
Sandman
In that case, what's the use of compiling to java source code, why not compile
directly to bytecode?

------
longpants2
I tried out Xtend, but got stuck on a deal killer: no apparent support for
defining static fields or methods.

[http://longpants2.posterous.com/first-experience-with-
eclips...](http://longpants2.posterous.com/first-experience-with-eclipses-
java-killer-xt)

------
roestava
I'm sorry to say, but I think the Go programming language has just been owned
by this Extend programming language for Java. Go missed the boat when it did
not include some minimum class support to appease the developers used to Java,
C++, and so on.

~~~
cmars
I develop with Eclipse and MDD at my day job, Go in my side projects. I'll
definitely evaluate Extend for the day job enterprisey stuff, but in Go, I
don't miss the class hierarchy at all; I find it very refreshing.

~~~
roestava
Go is cool. Go isn't too fast and doesn't have as much tool support as
Java/Xtend. Go may be great if you're doing network programming on Linux. Like
many tools originating from Unix environments, the cross-platform support may
not be a top priority.

You're set as you already use Eclipse. :-)

~~~
luriel
Go's cross-platform portability is quite good, writing portable Go code is
infinitely easier than writing portable C or C++ code, and probably as easy or
more than Java.

------
rshm
Does this remind anyone of Borland era ? At least for now it is an editor
centered solution.

------
ehynds
No one else is upset about the HTML 2.0 doctype on the examples page? WHERE IS
THE OUTRAGE? <http://www.eclipse.org/Xtext/xtend/#templateexpression>

------
PaulHoule
How do I make it work with mvn?

------
martiell
I don't see any mention on how to build outside the IDE (say, on a CI server).
Are there Ant tasks? Maven/Tycho integration?

These things are important. Where're the docs?

------
zackb
I like seeing the JVM becoming a platform. Even if this particular language
looks a bit silly compared to the others.

------
sjwright
According to that page, their new switch expression is very _egelent._

------
mike_ivanov
> compiles to readable Java code

[insert your favorite Ratfor joke here]

------
perfunctory
Building a language on top of java is a deadend.

------
srik
Granted Im not the target market, but Implicit returns do not seem like a good
idea.

~~~
famousactress
Yeah, is there precedent for that? It looks fucking nutty. Can you do it in
the middle of the function!? So odd. There's a lot of cruft in java, but I'm
not sure the return statement is even on the list of things I'd bother
attacking.

~~~
rayiner
Lisp, Dylan, Smalltalk, ML, Haskell, CoffeeScript, and Dart all have various
levels of implicit return. It makes sense in a language where there are no
statements, just expressions.

Generally code is written to not need to return from the middle of a function.
This is only really inconvenient in loops, and at least Dylan, Lisp, and
Smalltalk make some provision for an "early return."

~~~
Roybatty
Someone said Dylan so I just respond...my favorite language of all times :)

------
davidhansen
This looks to be an also-ran related to the Project Kotlin that JetBrains
launched some time ago:

<http://confluence.jetbrains.net/display/Kotlin/Welcome>

Also:

<http://news.ycombinator.com/item?id=2784086>

------
shareme
okay folks..

Quick explanation..

Its a text based java dsl..so in other words I could develop in xtend an
android application model that covers my dev use cases and than have an
Eclipse plugin that is for that model.

------
mkramlich
Does not look impressive to a Pythonista. _yawn_

------
Roybatty
Scala had its chance, and it didn't work...no matter what Martin and his boys,
and his minions want.

Kotlin will take over Java. That is fact. Mark my words on 11/05/2011.

~~~
SWengineer
You've repeated those sentiments up and down this thread. Personally I don't
see much difference between the two, even syntactically. I've seen scala
starting to get a foothold at my organisation, but haven't heard of anyone
discussing Kotlin. What is also interesting is doing a trends search for scala
jobs at indeed.com It looks like Scala has started to get a small but very
rapidly growing slice of the job market

------
mrerrormessage
you can dress up a pig...

------
siasia
yet another Scala

~~~
jaaron
It's not just Scala, it's Groovy, BeanShell, Factor (JFactor now), Fantom,
Frege, Kotlin, Ceylon, Stab, Gosu, Mirah, and that's not counting all the
ported versions of Ruby, Python, Lisp (Clojure) and so on.

What you haven't written a JVM language yet? It used to be you weren't a
proper programmer until you'd gotten fed up and written your own CMS or web
framework. Now I guess everyone has to have their own programming language.

~~~
rayiner
It's not so surprising.

You remove one of the major pain points of developing your own language
(platform/libraries), thus reducing the costs of writing your own language,
which shifts the industry to a point where there are more languages.

------
joelbirchler
this is stupid

