Using Closures in Java

In the last years, fuctional programming languages such as Haskel, F#, and clojure, have gained acceptance among programming enthusiasts. They allow a concise style of programming that is not easy to replicate with imperative languages.

Much of the power of functional programming languages is linked to the existence of closures. A closure is a way of binding variables to function definitions, so that you can refer to the variable later from the body of the function. The way the concept works is similar to fields in an object, but without requiring the existence of a class. This means that, in general, functions can have the same power of classes in an OO language.

For example, in common lisp one can write something like this:

(defun f ()
  (let ((x 0))
    (function (lambda ()
                (print (incf x))))))

(defvar add (f))
(funcall add)
(funcall add)

Here, we are creating a function f that returns a function (as defined by the lambda form). However, the returned function increments the value of x, which is a variable internal to the function f itself. Now, every time we call add, we are in fact incrementing and printing the value of x. Thus, the result of the execution of these lines is just

1
2

 
In this example, the function add has access to the internal variable x, defined in the let scope. Notice that, each time we call “add” we are incrementing that internal variable, even though the function f has ended — now, that is a trick!

Doing something like this is a non-functional language requires the help of OO. In Java, it gets a little ugly. In the following, I show how we can define a general interface for a unary function. This interface can be implemented so that some variables are bound, in a way similar to a closure.

import java.util.ArrayList;
import java.util.List;

public class Test
{
	interface UnaryFunc<T> {
		void exec(T t);
	}
	class ListIt<T> {
		List<T> l_;
		public ListIt(List<T> l) {
			l_ = l;
		}
		void apply(UnaryFunc<T> f) {
			for (T e : l_) {
				f.exec(e);
			}
		}
	}
	private UnaryFunc<Integer> getClosure(final int x) {
		final int[] total = {0};
		return new UnaryFunc<Integer>() {
			public void exec(Integer t)
			{
				total[0] += (t + x);
				System.out.println("x val: " + x  + " t: " + t + " total: " + total[0]);
			}};
	}

	protected void useClosure(UnaryFunc<Integer> f) {
		List<Integer> x = new ArrayList<Integer>();
		x.add(2);
		x.add(4);
		x.add(5);
		x.add(6);
		new ListIt<Integer>(x).apply(f);
	}

	protected void callClosureAcceptingMethod() {
		useClosure(getClosure(20));
	}

	public static void main(String []args) {
		Test t = new Test();
		t.callClosureAcceptingMethod();
		// print:
		// x val: 20 t: 2 total: 22
		// x val: 20 t: 4 total: 46
		// x val: 20 t: 5 total: 71
		// x val: 20 t: 6 total: 97
	}

}

What is going on here? The main action happens on method getClosure. The returned object is just the representation of a function. The variable total is being hold by the function object, and each time the function is executed, it adds the given value t. Also, notice that not only a local variable can be part of the closure, but also the parameter x, which is also added each time the function object is called.

Finally, notice that only a final variable can be used as part of the closure. This is a limitation of Java. For that reason, if we need a place to hold mutable data, we need to declare an array with one position (as we did with the total variable). It is a nuisense, but not really difficult to remember.

What about C#?

The current version of C# is much more friendly to users of closures. Moreover, the above example can be written much more easily — C# simplifies all that by using delegates, instead of requiring us to create a separate class just to hold the anonymous method. It also supports automatic type detection, which is another plus. But this is probably a good subject for a future post.

The Power of Doing the Right Thing

If you have participated in any way of the software industry in the last few decades, you have certainly seen the pattern of software development. Most software is built under the pressure of deadlines. Specially when a company wants to beat its competitors in a tough market, there is an increasing pressure to deliver software as quickly as possible. And things have not changed much: it was like this with PC software in the 80s, web browsers in the 90s, and more recently SaaS and iPhone apps.
Under such a hectic work pace, many programmers forget what I call the number one rule of developing good applications: always do the right thing. Although it is hard to define what the right thing is, it is really easy to define the opposite situation. If you write a program in a way that you know you need to revise later, and you don’t do this immediately, then you are not doing the right thing.

Paying you Debt

The main problem with not doing the right thing in code, is that, like in real life, you are creating larger and larger debts in your programming account. As a result, to progress further you need not only to implement whatever feature you originally coded, but you also need to fix whatever was left unfinished. And we are not even talking about the fact that there might be other bugs that you overlooked, hidden in the code you left unfinished.

Redeeming your Sins In Code

The power of doing the right thing, however, is great. When you for example write the right function (a generic one), instead of the bare minimum to make the program run, you are creating a basis that can be further used to build the whole program. You are not only fixing an immediate issue, but also saving countless hours further down the development line.
That is why good programming is somewhat non-intuitive, if you not an initiated. To be good at it, you have to code the slow way, at least in the first stages. That is, you have to look for code that not only solves your immediate needs, but that is robust and generic enough that can be used in other situations.
The naive developer will probably try to cut corners and finish the initial stages of the program as quickly as possible. The good developer, however, will take more time to create a really good solution, which will enable to proceed at a much quicker pace in the later phases of the project. 
After some iterations, from the point of view of the naive developer, the good one is proceeding at an amazing speed, which he doesn’t really know how to achieve. The reality is that the speed is just the result of doing the right thing several times, and using the results of each step to provide the foundation to the next software layer — and doing this with increasing confidence. While this virtuous cycle continues, the naive developer is still sorting out issues that he should have solved long ago…

Why great programmers don’t make as much money as soccer stars?

In a recent blog article, Soon Hui considered the different in pay scale between highly skilled developers and stars in other fields, such as music and sports.

It is not hard to understand why they can’t do as much as rock stars. The main reason is that programmers are not able to run the show alone. Programmers have to work in a team if they really want to do anything of moderately large scale. However, this is not the whole reason for the comparatively low pay scale, because there is another category of stars that make millions and need to work on teams to make things happen: soccer players.

In the world of soccer, however, the difference is that the quality of the team is highly influenced by quality of its best player (being a Brazilian, I am very familiar with how soccer teams work). It is frequently the case that, in a competitive league, just having the player won’t be enough to win the title, but it will make a heck of a difference. You can certainly see where a very talented soccer player is, even if he is playing in the worst team in the world.

In the other hand, there is no magic that will make a team with bad developers to deliver good products. Even if the best programmer in the world is in a team with other 10 average developers, he won’t be able to cope with the amount of bad code their pairs will throw at the project. In soccer, the highly skilled player will make good plays no matter what. In software, the highly skilled developer won’t be able to move, under the weight of tons of bad code. There is evidence that the quality of software produced by a team is highly influenced by the second worst programmer, not by the best one.

In a situation where average developers are involved, having a super star developer doesn’t help. What solves is having a skilled manager, that will be able control by whatever means the damage that each member of the team is inflicting in the final product. That is the (sad) tale of software development in more than 90% of programming shops. It is not a mistery, then, that being a software manager, especially a good one, pays much more on average than being a good developer.

Clearly, it doesn’t need to be like this. One could have a team of stars, each one making much more than average developers (think of the equivalent to the Dream Team). In reality, though, there is a reversion to the mean in industrial activities like software development. A Dream Team would need to produce more and more software to keep up with the demand, and this would lead to the necessity of hiring less skilled developers. And you can see where this goes…