Skip to main content

BGGA FUD Busting - Part 1

Posted by brucechapman on February 27, 2008 at 12:46 AM PST

Josh Bloch makes some interesting points in his Javapolis presentation on the closures controversy. However having listened to the audio several times and read the slides at least three times, I am having trouble extracting the salient points from all the FUD

(The presentation video of the talk is now also available)

What seems to be happening is that much of that FUD is starting to spread.

In this post I want to expose one of these items of FUD to some light and see how it really looks. Also I am hoping that having neutralised the noise, I might more easily extract some signal from Josh's talk. I think its there but I can't hear it just yet.

At 13:06 into the sound track, Josh starts comparing interfaces to function types by first refering to these javadocs for an interface and talks about it having a name, all known implementations, and documentation including semantic constraints. He then says

"with functional types all you get is 'it takes two T's and gives you a T'. There's a lot less information there."

This presumably is in reference to where the types are used. Compare this version of a method in the fork join library with this one using closures.

An Ops.Reducer is of no value except where it is used. Now with the non closures version, all we see in the javadoc for the reduce() method is the names of the type and parameter, whereas with closures we see the essential method signature, because that is the closure type, and the parameter name. The closure version tells me more because all I get without the closure is a type name and a parameter name, and if I want to know more I have to click a link to go find it. With the closure I don't ned to first follow the link.

Recently Stephen Colbourne tried to give more impetus to this FUD when he said

"A second complaint about function types is that there is no home for documentation. One of Java's key strengths is its documentation capabilities in the form of Javadoc."

To date I haven't seen anyone describe how the javadoc tool would work for closures, so let me suggest that when a method return type is a function type, or a method parameter is a function type, then the return and parameters of that closure type will be able to have nested javadoc associated with them.

I would expect you'd find the javadoc for ParallelArray.reduce () being something like



reduce

public T reduce({T,T=>T} reducer,
                T base)


Returns reduction of elements






Parameters:
reducer - the reducer. This function must be associative.

reducer returns
The result of combining the two arguments in some way

reducer parameter 1
The first argument to be combined.

reducer parameter 2
The second argument to be combined.

base - the result for an empty array
Returns:
reduction




You could do that now, but some new javadoc tags to do the nested documentation would make life simpler.

For sure those are pretty terrible javadocs, I just made them up, but this demonstrates that the function type's javadocs can be just as rich as the nominal type's.

Before you say it would get tedious writing out the same complicated javadoc at every place where you used a particular function type, let me say that the point at which it gets painful is probably the point at which you should consider using an interface rather than a function type, and the javadoc pain is your friend by helping you to see that.

And one last thing, Josh says that with an interface, you can find all the known implementations from the javadoc. Not so, you won't find the implementations that are anonymous inner classes. And those are exactly the sorts of places where you would use nominal types and closures. So that's not really an advantage of nominal types over function types in the places where you'd actually use them, it's just more FUD.

Related Topics >>

Comments

An interesting article... but was in necessary to frame the debate in terms of FUD and FUD busting? Some people have concerns and raise questions, if they are incorrect that may not mean they are deliberately lying.

While some of your mini-rant sounds like a slight misinterpretation of Bruce' talk (which surely compares the types' documentation and not the parameters documentation) you make one really interesting and, to me, important point: "the point at which it gets painful is probably the point at which you should consider using an interface rather than a function type". In my opinion, function (or method) types should be used in places, where no semantically useful interface could be defined. Having generic callback SAMs named "Procedure" or "Function" are such examples, where the only documentation on the type would be generic blah blah corresponding to what a function type would read: "takes types X and Y and returns a Z". Hence, the application scenarios for SAM types and function types are complementary It's not a FUD, but using the wrong tool for the concrete situation. Btw., as far as I use eclipse, it does find anonymous inner classes.

Bruce,

I think you misunderstood my argument. I was talking about the documentation (and specification!) of the type, not the parameter. If the parameter is the only place that you can put the documentation, then you have to repeat the documentation every time you need a particular structural form (such as {T,T=>T} ) with a particular specification (such as "the function must be associative"). These contracts can be quite complex (e.g., java.util.Comparator). And once you have a name, you can search for implementations, with your IDE, or with simple text-based tools such as grep. To quote Doug Lea, searching for "{T,T=>T}" is about as useful as searching for "int".

I may not have made my point clearly, but it is not FUD. It really is the case that nominal types are far richer than function types. Nominal have names, contracts, and meaningful documentation for the type itself. Because the documentation applies to every use of the type, you don't have to repeat it each time you use the type for a parameter.

Josh

Agreed that saying it is FUD may be somewhat strong, differing opinions in a multi sided debate are just differing opinions. I am starting to see how Josh may have a point about documentation tool logic and such as it is currently may need enhancing - but it makes the actual usefulness of BGGA no less compelling. It's simply a different problem that needs a solution. BGGA already solves the biggest actual programming / logic problems we've all wanted for so long, so the other facets seem less important if people are attempting to use them as a reason to dismiss BGGA. (ie don't throw the baby out with the bathwater) I still don't understand how - after programming java code for years on end - you can not want to jump all over BGGA...esp if you've had any experience with dynamic languages.....I've yearned for mix-in / closure like functionality in java and BGGA seems to come "close enough" to make this possible finally. Maybe you guys could just combine forces and address the javadoc / tool / other valid (though still not as important as the actual functional part) concerns one step at a time. Please don't take away our chance at having mix-ins (sort of) and reducing the amount of crazy class hierarchies or runtime bytcode manipulation we have to do without them.. =(

Josh I agree that nominal types are richer, and in cases like Comparable, having a nominal type with a central place to hold the documentation and add semantics is really useful.

There are other places where that argument doesn't apply, just as there are places where primitives are the correct way to model something even tho' its pointless to grep for their types.

Here is a copy of your slide. Is this a fair comparison? What is being compared and where did you get them from? Would it not have been fairer to compare to the reduce method's javadoc on the right (issues of formatting the slide aside). I think your comparison was unfair, and whether intentional or not, other posts are starting to repeat the paraphrase that function types have no javadoc. Some information was omitted and people are drawing a wrong inference from what was presented, that wrong inference then affecting their judgement of Function types toward your position. So it probably wasn't misinformation as defined on wikipedia, but it seems like misleading (in terms of lacking objectivity) information to me. I had no intention of implying you were "deliberately lying" as lars westergren put it. If that's how it came across, my apologies.