API Design & Closures

In a recent design discussion, I've noticed that the preferred java-ish approach is rather verbose.

Suppose we want to create an expression tree and evaluated-it:

solution1:
ExpressionTreeBuilder b = new ExpressionTreeBuilder();
b.newExprY(a,b);
b.newExprX(c,d);
....
ExpressionTree t = b.toTree();
interpreter.eval(t);

I find this solution rather difficult for 'beginners', the people who see the API for the 1st time. As a 1st time user of the API, I discover the interpreter as a service, and I start searching for the ExpressionTree to give it to the interpreter. I find the class, but it is immutable. I finally, redirect myself to the ExpressionTreeBuilder and I realize how can I use all the parts properly. IMO the above approach has a detective-trying-to-solve-a-puzzle feeling, exposing too much of the implementation mechanism.

A much cleaner solution would be:
interpreter.eval { |b|
b.newExprX()
b.newExprY()
}

This solution has a single point of entry and the user is directed to the correct API usage. The intermediate build/transform steps are hidden. It reminds me of scala loan pattern, or ruby html builder.

Java language EOL

via InfoQ, link to the original ThoughtWorks paper:

The authors mention the fact that Java has been slow in adopting new features lately, the initiative being taken by other languages built on JVM, “languages such as Groovy, JRuby, Scala and Clojure.” They expect enterprises to “begin to assess the suitability of reducing the amount of Java-specific code developed in their enterprise applications in favor of these newer languages.” Because of that, the authors suggest assessing the end of Java as a programming language.

This boils down to closures. If you start a new project, you could start with a project which allows you to do much more then just java. Related presentation: Language Parity: Closures & JVM.