The Cafes » Blogroll

I’m slowly coming around to the idea that first class functions in Java are probably a good idea. I’m still not convinced we need full-blown closures though. Possibly we do. Doug Lea has some interesting use cases I need to explore further.

Several things concern me though. One is syntax. I really, really want the syntax to be simple and have no surprises or significant learning curve. I want existing Java programmers to be able to read Java code that uses closures (or first class functions) and immediately be able to see what the code is doing without any prior training in the new syntax. I want the syntax to be that clear. If we can’t have that, I don’t want to do it. I want Java to still be a lingua franca.

Secondly I want closures to be really, really easy to write. No gotchas. A little training may be allowed here, but there shouldn’t be any special cases or surprises. Programmers’ first instincts of how to write something should be correct. In particular, I do not want to see any issues like “the closure works if the external variables are declared final, but fails if they’re not.” Or, “the closure works if the external variables are not modified, but stops compiling if a line is added that modifies one.” That is, implicit final is not a workaround. The only things that break the closure should be:

1. Syntax error inside the closure itself
2. Breakage in the closure syntax (i.e. leaving off a trailing curly brace or some such in the closure definition)
3. Removing or renaming an external variable the closure depends on.

In other words, the only things that should cause a closure to fail to compile or run in the expected fashion should be exactly those things that cause today’s code to fail to compile or run. If you rename a local variable from x to y and forget to rewrite the statement foo(x);, then the compiler complains. This is a common bug we all know how to handle when it happens to us. I want to make sure that adding closures does not add any new failure types or patterns.

Those are my requirements for any proposal to introduce closures or first class functions into the Java language. I am prepared to reject any proposal that does not meet these two criteria. If no proposal can satisfy these two criteria, then we shouldn’t add closures or first class functions.

So what are the proposals on the table, and how well do they meet these criteria?
(more…)

There’s one example that comes up sooner or later every time someone starts talking about closures. This time it’s from Bruce Tate on developerWorks:

Listing 1. The simplest possible closure

3.times {puts "Inside the times method."} Results: Inside the times method. Inside the times method. Inside the times method.

times is a method on the 3 object. It executes the code in the closure three times. {puts "Inside the times method."} is the closure. It’s an anonymous function that’s passed into the times method and prints a static sentence. This code is tighter and simpler than the alternative with a for loop, shown in Listing 2:

Listing 2: Looping without closures

for i in 1..3 puts "Inside the times method." end

Personally I find the latter example simpler, clearer, and easier to understand. For one thing, when I see the word times suffixed to a number like 3 I expect multiplication, not action. But even if times were changed to a more reasonable method name such as do or act, I’d still prefer the for loop. (Perhaps what you really want here is “do 3 times”. That might really be clearer. )
(more…)

When I travel I speak English. When I teach I speak Java, and for the same reason: it lets me be understood.

When I need to teach cross-platform subjects like DOM or data structures to mixed language audiences, I can easily use Java to show examples and everyone can follow them, even if they’re not Java programmers. Everyone reads at least pidgin Java. Only C++ programmers can read C++. Only Ruby programmers can read Ruby. (Still better than Perl though. No one can read Perl, Perl programmers included.)

Of course, if you’re traveling in one area, it’s better to speak the native language if you can. French gets you farther in Lyons than English, but if you’re at an international conference, English is your only hope. If you’re at RubyConf, Ruby will get you far. However if you’re at OOPSLA or Software Development, Java is the way to go.

Java is the programmer’s lingua franca.
(more…)

I’m still trying to wrap my head around closures, so I can decide if they’re a good idea or not; but there is one specific proposal I am willing to shoot down: Concise Instance Creation Expressions by Bob Lee, Doug Lea, and Josh Bloch. In fact, I think they shoot it down themselves pretty effectively without noticing what they’ve done. Here are their examples:
(more…)

There’s an awful lot of sound and fury right now about adding syntax support for properties to Java 7. However, all the proposals are vastly too complex for what little benefit they offer. They need new keywords, operators, rules, and best practices. Could we have done better? Yes. Can we still do better? Maybe. Let’s find out.

The proper design of properties was invented in Eiffel over a decade ago, (or possibly some other language, but Eiffel is where I first saw it) and it’s really simple and obvious. All you need are public fields.

Oh my god! Public fields! The ultimate evil of object oriented programming that will bring about chaos, catastrophe, and the heat death of the universe! He can’t be possibly be serious, can he? Well, yes I can, because public fields don’t have to be bad.
(more…)