Eclipse launches new language to cut down Java boilerplate - Extend

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

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.

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

The major downsides which are super troublesome are that it takes 2 minutes to build each time - even for trivial changes and I have to debug the old school way with messages.

    (function () { });

LISP is the second-oldest HLL there is. As a syntax and a way of structuring code, S-expressions have been around since before the vast majority of software developers were born. Despite what one might be read to believe in reading the self-promoting protestations of Paul Graham, it has never gained much traction outside a few ivory tower settings. If it were going to take the world by storm, it should have done so by now.

The syntax is a major stumbling block for the vast majority of programmers, including a number of very smart people. This is not because of some failing on the part of said programmers. It is a simple by-product of the fact that its primary design goal was not to be a language in which humans can conveniently arrange and express their thoughts. It just wasn't; this was an era where coding in machine language was still common, and where the things language designers could dream up were severely limited by the rudimentary parser and compiler technology of the time.

As time passed and technology permitted, almost all the world came to settle on a certain principle in language design: Things that behave differently should look different. This is not trivial. It is a principle that is guided by the fact that human brains are designed to distinguish things by shape first and foremost. Parsing is more difficult and time-consuming, and so languages that minimize the amount of parsing that humans must perform will be easier for humans to use. There is but one remaining community which holds out against this simple truth: LISPers.

With modern technology we have a new crop of languages, ML and its descendants such as Scala, which adopt and expand on the principles that made LISP stand out so many decades ago. And they have the added advantage of being designed such that different things look different, and so people tend to have an easier time using them. And we see rapid adoption of these languages, and popular opinion agreeing that they are Good and have much to offer. Thus the key thing which makes LISP great finally sees vindication in the world at large, and the idea that LISP championed, the idea that processes are primarily composed of verbs rather than nouns, becomes transcendent.

And yet, there are still so many LISPers who continue to hold out, and refuse to accept this victory, because it is a victory that lacks S-expressions and their trademark parentheses.

And yet, they think it is everyone else who is irrationally hung up on syntax.

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

Are you part of Groovy's echo system too?

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

As someone from outside the Java universe, I'd like to learn more about those reasons and why they are obvious.

I'd say it's about as functional as Python... which did get a lot of traction lately in various different places.

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.

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.

Also it supports picking up changes in the configuration of major frameworks, like spring, for example.

Basically, with JRebel you can develop in java as you would do in python :)

disclaimer: I'm employed by the company that develops JRebel, but this fact doesn't make it any less awesome.

All those new "cool and innovative" languages are just rediscovering it after almost a decade of everything with C syntax.

Not that it's bad or anything, it's just my OCD tingling.

I think the idea of computed fields implemented via methods is better represented via C#-style properties, although I'd prefer to be able to access their methods directly, when suitable.

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

This trend of trying to strip programming languages down to their "essence" is a fools errand and the pendulum will swing back eventually (not fast enough in my opinion).

    greetABunchOfPeople List<String> people
        people do
            _ sayHello println

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

  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;
    }
  }

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

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

The JVM would never know.

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

App Engine also supports Python and Java. I figure folks could use Xtend to write Java web apps that cut some of the boilerplate and perhaps even deploy to App Engine, for instance. Giving folks an alternative to going with Go as a static typed language.

Perhaps Xtend using Java source-code as an intermediate medium confuses people a little. Using Eclipse to program using Xtend/Java may just be too seamless for it not to matter much after you've grown used to it.

Where did you see that it says you can do it in the middle of a function? I understood it implicitly returns the last expression.

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

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.