Re: The Closure Controversy
Jon Harrop wrote:
My final feeling about Joshua's statements is one of agreement. Trying to
retrofit real functional features onto Java is completely futile and cannot
yield anything usable. To make such things usable you must completely
overhaul the language, fixing the fundamental problems first and, if you do
that, why not doing it properly by simply building a whole new language for
the JVM?
Bloch--I would prefer to use the last name in this discussion, as
`Joshua' is an extremely common name and two people with said name are
now going to be involved in the discussion--notes at one point that the
decision to not make the primitive types extend from Object was perhaps
a bad one. Indeed, some of his dislike for BGGA closures comes from its
inability to handle auto{un}boxing.
True, pure functional programming (at least as Wikipedia describes it)
cannot succeed in Java:
Functional programming ... treats computation as the evaluation of
mathematical functions and avoids state and mutable data.
Since object-oriented programming emphasizes encapsulation of state and
mutability--indeed, methods without side effects should be rare in
OOP--functional programming is the exact antithesis of this. Even if
functional programming is the new "in" in programming, Java is, always
has been, and always be OOP; forcing this new paradigm onto it would be
painful and ultimately (IMHO) fatal.
But Bloch also points out that closures seek to solve several problems
(perceived or real) in Java:
1. Verbosity in anonymous inner classes
2. Difficulty in instituting callback
3. Inability to create pseudo-control structures
4. Verbose and error-prone resource management
5. Difficulty in parallelization
Closures, at least in the BGGA proposal, are the poorest way to tackle
all of these:
1. Verbosity is traded off into short-but-confusing code snippets.
2. Function pointers are helpful, but they are prone to extremely poor
documentation. Syntax is also barbaric.
3. The only two pseudo-control structures that seem to be pondered are
the ARM blocks similar to C#'s using and multivariate for loops. Of
these, the former could be solved with a simple syntactic-sugar
modification, and the latter isn't terribly high on my list of things
that I need. Tackling this also creates the most complexity.
4. See answer to point #3.
5. I don't really see how BGGA solves this problem.
I recall browsing a BGGA closure discussion which brought up that a
return
can be different, in some cases, from a
return;
The discussion here was telling. One proponent was saying that the
difference between the two can be easily remembered because the
semicolon version is doing a non-local return and the other the local
return (closures returning void are SERIOUSLY confusing). If the
presence or lack of the basic statement delimiter has two different
/compilable/ effects, then the proposal is *seriously* flawed.
Here I am also mostly in agreement with Bloch on this four points:
1. Not that much of a problem. Modern IDEs make it extremely easy to cut
through all of the overhead code. I don't use a modern IDE, but I abuse
the anonymous inner class syntax, and I don't complain about it's
verbosity. Au contraire, it can be beautiful.
2. Function pointers will do more harm than good unless done right. And
I don't really see how they can be done right.
3. Pseudo-control structures begin to risk fracturing Java into dialects
much the way C has. I see very little use for these structures, except
for...
4. ... this one. And Bloch's idea to solve this is good enough for me.
5. Simple but powerful parallelization techniques are still in the arena
of cutting-edge research. And I believe that what is research does not
belong in a production language.
Everything said, I believe that closures present a problem for Java. A
large community seems insistent on pushing closures into Java at the
expense of tackling other problems. I believe that the problem of
generics need to be solved before any other new feature can gain entry.
But the efforts that could be used to best fix these problems are going
into presenting three or four conflicting versions of closures and
expanding these versions to make Java more functional.
I thought Joshua's welcome slides that described how Java was built to be
used by industry and not as a PhD thesis in academia was right on the
money. Consequently, I was very surprised to see Joshua recommend the Scala
programming language, as this is academic research.
I, on the other hand, was not surprised: Bloch points out near the
beginning that Java was designed to be an operational language, a mixed
language (I forget his exact wording) as opposed to the research
languages. It seems to me that he is of the opinion that languages like
Scala are designed to be researched on, that is, to be sliced, diced,
cut, and mutilated for the purposes of deciding which features should
and should not be placed into a new language. It is in this vein that I
think he intends to recommend Scala.
This got me thinking, industry would benefit enormously from the creation of
a modern statically typed functional programming language that combined the
tried and tested benefits of languages like OCaml and Haskell with the JVM
platform. Will Sun or someone else build such a thing?
I do believe that someone has already built such a thing. However, I am
going to bring to mind one blog praising "The Next Big Language". What
will it be? Ruby, Javascript, Groovy, and others were tossed around
without consensus. But these languages are all similar in one way: they
gain a sizable following, generate a fair amount of hype, and then...
nothing happens. What industry really needs is for there to be one
language that specializes and focuses in this new area without strong
competition as opposed to competing jack-of-all-trades. After all, who
makes more: the master goldsmith or the jack-of-all-trade smith?
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth