Effectively final

[Tim Fox]

On 15/08/2011 22:04, Rémi Forax wrote:
> On 08/15/2011 04:41 PM, Tim Fox wrote:
>> Actually I am really disappointed by this. If these kinds (I.e.
>> closure/CPS style programming frameworks) of frameworks take off in the
>> JVM world, Java is going to be the ugly kid on the block for programming
>> in them. No such problem with Ruby, JavaScript, Groovy, Clojure,
>> Scala.... As a long time Java programmer, I think it's a real shame that
>> Java the language fails to modernise at the rate required to remain
>> relevant. Love the JVM though:)
> I don't know for Scala but all the other languages you cite introduce
> capture of local variables because Lisp have it.
> Lisp was not created with multi-core in mind :)
It's certainly true that many programming languages weren't invented 
with concurrency in mind, and their support for concurrency is limited 
or non-existent. JavaScript and Ruby are good examples.

However, that doesn't mean they can't scale on multi-cores. There are 
other ways of scaling such programs on multiple cores without letting 
your objects be accessed by multiple threads concurrently. If you can 
guarantee that your code is only accessed concurrently by at most one 
thread (or even better by the exact same thread), then you don't have to 
worry about concurrency, and closures that capture local variables are 
not a big deal.

This can be done by partitioning the set of objects in a process into 
quasi-independent islands. In a particular island it's guaranteed that 
the same thread always executes, so the developer can write all their 
code as single threaded. This is a huge win.

IMO this pattern is going to get more and more popular, especially as we 
see other languages getting popular on the JVM (JRuby, Nashorn) The 
alternative is horrible. Can you imagine having to apply the Java memory 
model to JavaScript? Can you imagine JS developers having to reason 
about Java concurrency? It doesn't bear thinking about.

For Java devs too, being able to write scalable applications without 
having to worry about concurrency is a huge win. This is why "real" 
closures are important.

Ignore the "edge case" at your peril!
>
> If you want to capture local variables, you have to at least:
>    - introduce a pass by address semantics to Java,
>      something which is alien to Java and that will require VM+JIT supports.
>
> - find a non stupid semantics for algorithms that are inherently non serial
>     int sum = 0;
>     parallelArray.forEach( #{ it ->  sum+= it; });
>
> - invent a new semantics for a volatile local variable and
>     a way to express compare and swap on it
>
> - figure out how to serialize such beast
>     (Java lambdas need to work in a Hadoop like environment)
>
> And all of these for a corner case (see [1])
>
>> Just my 2c of course.
> So I think it's better to disappoint some people and educate everyone to
> use reduce:
> int sum = parallelArray.reduce( 0, #{ element, sum ->  sum + element });
>
> my 2c too.
>
> Rémi
> [1] http://www.artima.com/intv/closures2.html
>
>
>