RE: accumulator generator (Java)

["Anton van Straaten" <address@hidden>]

> > Of course, this uses an object ("to simulate a closure", if you like) as
> > opposed to "pure" functions.
> >
> > Can we do better in Java?  Well, sort of yes, but mostly no.
>
> I don't understand how you can do "better" than using a core language
> feature exactly as it was intended to be used, in a manner that is
> completely clear.

I meant that part of my message in a lighthearted sense, and attempted to
meet the challenge implied in PaulG's requirement, which was "define a
function that takes a number n, and returns a function that takes another
number i and returns n incremented by i."

This can't actually be done in Java, exactly as written, unless you are
willing to call an object "a function" - which isn't such an unreasonable
position, given the close relationship between objects and closures.

> The only sense in which your other solution is better
> is in that it more clearly apes the Lisp way of solving the problem.

I'm not sure if you noticed, but my other solution was illegal Java, so
really not a solution.

> That's my overall problem with this particular microbenchmark.

I don't know exactly what PaulG had in mind, but the benchmark does clearly
illustrate how well a language can define closure or object-like constructs
"inline", without separate definitions.  Even with Java's ability to create
anonymous inner classes, a separate definition of an appropriate interface
or class would be required.  This makes Java more verbose, in cases like
this, than languages which support independent inline creation of this kind
of construct.  That's a valid test.

In fact, I use Java in my work, and can attest that its tendency towards
verbosity, of which this is just one example, is a prominent characteristic
of the language, which alone provides a strong justification for tools like
AspectJ or Elide.  Personally, I generate a lot of Java code from XML
definitions, and try to treat the language more as a kind of target platform
(i.e. the platform used by commercial application servers) than a language
in which to author source code.

So, I'd say PaulG's benchmark neatly demonstrates an important point.
Perhaps the requirement could be reworded to make it clearer what is being
illustrated, and what the goals are, but I'm reminded of the comment about
how this list hasn't been sufficiently anal so far...

Anton