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