Joe Walker - closures tag

Comparing the Evolution of Java and JavaScript

Mon, 17 Dec 2007 13:19:28 GMT

Java:

Java is the most used language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling Java to accommodate more programming styles (e.g. functional programming via closures). Others believe that being lightweight is a virtue.

JavaScript:

JavaScript is the most deployed language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling JavaScript to accommodate more programming styles (e.g. by adding classical inheritance not just prototypal inheritance, and an optional type system). Others believe that being lightweight is a virtue.

Features:

It's interesting that the current simple version of JavaScript already has the features (i.e. closures) that people want to keep out of Java otherwise it will become too complex, and that Java already has some of the features (i.e. classical inheritance) that people want to keep out of JavaScript, otherwise it will become to complex.

Crossroads:

The Java language is challenged by languages such as Ruby, Groovy and even Scala, all of which support closures. The majority of people that have spent serious time with these languages prefer them over Java for at least some set of problems.

The JavaScript language is challenged by Silverlight. Microsoft try to avoid saying things like "death to Ajax", but secretly (or not so secretly depending on who you talk to) they would love to control the platform once more, and Silverlight is the latest attempt at regaining control.

Features vs. Complexity:

Joel noticed that there is a big difference between good developers and bad developers. Google noticed it with it's picky hiring process. On many projects there are a few developers that do all the real work, while others just slow things down.

But much of the "keep complexity out of the language" debate is aimed at helping the people that write less code anyway.

Nail-guns and angle grinders are dangerous tools, but the building trade accepts the danger in the name of greater productivity. In software development where the difference between good and bad developers is that much greater, and where developers don't actually get physically maimed, the argument for power over simplicity is that much stronger.

In summary, extra power helps smarter developers work more quickly, but makes life harder for less smart developers. Since a small number of smarter developers generally do better work than a large number of no so smart developers, we should tend slightly toward giving developers more powerful tools.

Java:

In Java, BGGA closures enable higher-order programming. It's hard to say that the addition of closures in and of itself would cause a complexity implosion, after all, Java is virtually the only modern day programming language without them. It could be argued that the Java language can't be evolved to accommodate them, but I'm leaning towards there being a net gain by including them.

Interestingly, Google Android contains a clean room re-implementation of Java. If Sun (or the JCP) accepts closures, and if (as seems likely) Google votes against them, what will happen to Android? Will it follow how Google votes, or how Java evolves?

JavaScript:

With JavaScript, people see a neat, compact language and fear it turning into Java. The good news is that it won't fully turn into Java because JavaScript already has closures and no one thinks they should be taken out ;-) The danger of the "features over complexity" argument, is that it can be applied indiscriminately, creating a monster, and the fear is that JavaScript will become a monster.

I'm gradually coming round to the opinion that many of the changes proposed to JavaScript actually reduce complexity. There are nearly as many frameworks that add classical inheritance to JavaScript as there are Ajax frameworks. Having one solution that we can all agree on can't be a bad thing even if you prefer prototypal inheritance.

*: For some value of simple. The exact definitions of simple used in these 2 paragraphs are not necessarily the same.

Emerging Java Technologies at QCon

Thu, 15 Mar 2007 13:42:19 GMT

I've just finished opening the "Java Emerging Technologies" track at QCon and spent some time talking about Closures. This is a summary of what I said:

You can look at closures as blocks of code that you can pass around for execution. You can look at them as syntax sugar for inner classes. I think there is some significant power behind full closures that you miss when just looking at them from those perspectives.

This is how you define an integer 'a', in Java:

int a;

This is how you define a function 'b', in a Java Interface:

String b(int p1, int p2);

This is how you define a closure 'c', according to the BGGA proposal:

{ int, int => String } c;

This defines a closure to which you pass 2 integers and it returns a String.

Another closure 'd' takes a String and returns nothing:

{ String => } d;

We can provide an implementation of this closure:

{ String => } d = { String m =>
    System.out.println(m);
};

And then execute the closure like this:

d.invoke("Hello, World!");

The standard example (standard because it is the one used in the spec) looks like this:

public static <T,throws E extends Exception>
T withLock(Lock lock, {=>T throws E} block) throws E {
    lock.lock();
    try {
        return block.invoke();
    } finally {
        lock.unlock();
    }
}

This example can be made much easier to understand if we ignore exceptions and return types for a while:

public static void withLock(Lock lock, {=>} block) {
    lock.lock();
    try {
        block.invoke();
    } finally {
        lock.unlock();
    }
}

This is a method that takes a lock object and a closure. It then surrounds the execution of the closure with lock and unlock commands.

Normally speaking you would use this as follows:

withLock(lock, {=> System.out.println("hello"); });

However there is a special rule in the closures spec that says: If the last parameter to a method is a closure then you can write the closure outside the parameter list like this:

withLock(lock) {
    System.out.println("hello");
}

It's likely that we would not have needed the synchronized keyword if closures had been around in the beginning. It's also likely that a large amount of Java could have been defined in terms of closures. For example:

public static <throws E extends Exception>
void If(boolean condition, {=> throws E} block) throws E {
    if (condition) {
        block.invoke();
    }
}

You would use this function like this (note the capital I on If:

If (a == b) {
  System.out.println("a equals b");
}

So closures as defined by the BGGA proposal allow you to do some fairly fundamental things with the Java language.

Closures: Cheers, Library Issues and Solutions

Sat, 19 Aug 2006 14:35:04 GMT

At last. But there is a problem...

I think the addition of Closures are the biggest change yet made to Java. Closures change the way you think about programs - a step change rather than a simple evolution like Generics were.

It's good to be able to do this:

int total = 0;
void(int) totalizer = (int i) : total = total + i;
totalizer(1);
totalizer(2);
System.out.println(total); // Prints 3

But what you really want is to be able to do things like this:

int[] numbers = new int[] { 100, 200 };
numbers.each(totalizer);
System.out.println(total); // Now prints 303;

This is a fairly serious problem. Without support from many of the system classes - especially Collections, closures are really quite limited. So this is why it's a real shame that it has taken so long to get Closures into Java.

I think the most useful additional collection methods would be:

each - run the closure once for each collection element
transform - return a collection of elements that are returned by using the closure once for each input collection element
all - return true if the closure returns true for all collection elements
any - return true if the closure returns true for any collection elements

On the face of it there are 3 options:

break backward compatibility
break closures by lack of collection support
add static methods like Collections.each(Collection c, Closure x);

Option 1 may seem like a good idea to many, but it won't happen. Sun are very strong on keeping backwards compatibility.

Option 2 is just giving in without trying.

Option 3 maybe the best, but it's not really a great answer.

However I wonder if there isn't a fourth option: Some extra syntax sugar like this could replace the need for things like Collection.each(Closure c):

for (numbers : totalizer);

Behind the scenes the compiler does this:

for (Object obj : numbers.iterator) {
  totalizer(obj);
}

Clearly this should work with anything that is Iterable and not just lists.

However, this doesn't fix the lack of all() and any() methods or transform() (unless we allow a return value from the new for loop). Might it be possible to create a syntax like this to cope with all eventualities? Maybe the new for syntax could optionally take 2 closures, the first was an action to take on each collection element and the second was a combiner that allowed you to specify how the loop functioned???

7 Things I Learnt at TSS-Europe

Mon, 26 Jun 2006 10:53:07 GMT

1. I learnt that Retroweaver actually works. Retroweaver tweaks your JDK5 compiled classes to make them work on JDK1.4. The JavaPosse had some doubts about it a while ago, but James Strachan and Geert Bevin love it. I'm thinking that DWR v2 will probably adopt this and drop the support for JDK 1.3. Please shout now if you need us to keep JDK 1.3 support.

2. I learnt that red wine and light blue t-shirts don't mix. Sorry Nathalie.

3. I learnt that OCAML is interesting language to teach your brain new tricks. Bruce Tate was talking Ruby up, as expected, and saying that programmers should learn a new language on a regular basis to keep on their toes. However I spent the flight home chatting to Alan Sexton who convinced me to take a look at OCAML and a better mind stretching exercise.

4. I learnt that a simple "hola" (hello) makes a big difference in Spain. I'm not great at foreign languages - I can get by in French, but only badly. I got an extra legroom seat on the flight home for nothing. It's either because the girl at the check-in was magnetically attracted to my rugged good looks, or because I smiled and said Hola. Anyone that has actually seen my rugged good looks will agree that Hola makes a big difference.

5. I learnt that continuations and closures still confuse lots of people. They are very different. Continuations are when you freeze a thread and serialize the stack to be re-run later. Closures are functions that can be assigned to variables where the functions can refer to variables in the enclosing scope. Nothing to do with each other, but often confused.

6. I learnt that it is a real shame industry and academia doesn't mix more. I can't see much in the Ajax world coming out of academia just because the Ajax world is spinning so fast, but there are some brains there that could certainly teach us a thing or two.

7. I learnt that many top universities still don't teach copyright/patent law as a mandatory part of their courses. This is a huge hole. How can you be a good programmer without knowing the basics of what ideas you can copy from others and when?