The Cafes » Blogroll

I’ve long been an advocate of outside-in API design. This reflects my interest in user-interface principles in API design. When designing a GUI it is customary to mock it up on paper and then with prototyping tools before implementing the internal code. This helps the interface reflect the user’s goals and expectations rather than the internal data structures of the program. In API design, this means the class becomes more easily usable by decoupled client code.

It occurs to me that the same principles apply in language design. In particular we should try writing some code with proposed new features before we implement the features. This has several advantages:

• Ensures we get what we need, rather than what the proposal supports
• Helps us understand exactly what is being proposed
• Shows the strengths and weaknesses of each proposal
• Avoids unnecessary features that don’t support a real use case

Consequently herewith are some challenges for the proposers of the various closure proposals. I’ve tried to make them as simple as possible so that the closure issues will be focused on.
(more…)

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…)