i clay,
True we agree on most "concrete" points :) I'll only make a fix, there is no
such a thing as my "personal defintion of closure"; in another message here
I defined closure as "the pairing between a function and an environment that
provides bindings to its free variables" - this definition is not subject to
debate, sorry. But that definition is vague enough to not include details
like whether mutable vars should be captured - precisely because these
details are distinct across languages (e.g. some languages do not have
mutable variables at all; other important features that interact with
closures in some languages: continuations, tail calls, MOPs...).
We disagree in higher-level, philosophical terms. But these are not
unimportant. I insist a lot in the concept of orthogonality, and this is
important because it boils down to complexity. Failures in orthogonality
cause a language to be more complex; this also is not opinion
("orthogonality" translates to "all pieces work together seamlessly"). And
in this case we're talking about complexity that is unnecessary (because the
solution is simple and VERY time-proven), and has no significant positive
tradeoffs. Yeah, Oracle claims that safer concurrency is such tradeoff, but
that's bollocks. People will just keep using hacks like creating a final
single-element array so it can be captured by the closure, and if the code
is concurrent that will be a bug because you can't make an array *element*
volatile. Then the programmer fixes that to use an Atomic object... but
that's still a bit of a hack, needing a special API instead of a
fundamentnal language construct for that. The whole problem would not exist
at all with mutable capture: no new technique would be ever necessary, the
programmer wouldn't need to learn anything new to make concurrency safe with
closures (just use volatile if the code is multithreaded - exactly like you
would do without closures).
I wholeheartedly agree that Java could benefit from steps towards functional
idioms, but this is a completely distinct discussion, and such improvements
cannot be made at the expense of the existing language, which core is
"purely imperative" and (whether we like it or not) will always be.
A+
Osvaldo
On Thursday, September 15, 2011 5:15:58 PM UTC-4, clay wrote:
>
> @opinali,
>
> "the major point of debate is whether Java's closures (with or without
> Java 8's lambdas) are 'good enough'"
>
> That's an important issue, but I want something less than that: I want
> people to communicate their thoughts and viewpoints using technically
> meaningful language.
>
> The Java Posse have repeatedly said "Java doesn't have closures",
> "Scala is basically Java with closures", "Java really needs closures".
> People are basically misusing the word closure to represent a variety
> of different issues and language features. My point is that you should
> use correct language so we can understand each other. If you think
> Java is terrible because it doesn't have first class functions or
> continuations, say that rather than use your own personal definition
> of the word "closure" and expect everyone to know what you are talking
> about.
>
> I think you, I, and most people in this thread have come to a
> reasonable consensus: Java absolutely has a limited but useful
> implementation of closures that is widely used. Moving forward, Java
> sorely needs to be improved in a variety of ways. That's a much bigger
> topic but for starters Java needs better closures and they should be
> married with first class functions and a better syntax for anonymous
> functions. Java should also have better support for side-effect
> immutable programming and have a high quality persistent immutable
> data collection library (guava has constant read only collections but
> not persistent immutable collections like Scala does).
>
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/javaposse/-/iKaZD9MP79sJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
