On 31 July 2012 07:43, Russel Winder <[email protected]> wrote:
> On Mon, 2012-07-30 at 21:52 +0100, Kevin Wright wrote:
> > The basic idea is that if you "insert" an Apple into a collection of
> > Oranges, then you get back a collection of Fruit. Both the new
> collection
> > and the original are immutable, with the original continuing to be a
> simple
> > collection of Apples.
>
> I have to admit that whilst a lot of programming is about transforming
> apples to oranges and comparing apples and oranges, the interesting
> stuff happens with very big data structures, for example 6GB XML
> documents, or 256MB images. You do not deal with these things by value
> per se.
Sure, you deal with them as immutable structures that you transform into
other immutable structures in a declarative fashion. i.e.
val uppernames = names map { _.toUppercase }
*nothing* about that expression suggests that you're working on a
value-by-value basis, or prevents it being run entirely in parallel. Nor
does it require message passing or any other concurrency formalism in order
to do so.
This is very akin to the style of "programming" that you see in SQL, XSLT,
etc. So it's not a "niche" technique, nor is it a bleeding-edge unproven
technique.
The solution at the moment is to switch from a shared memory
> perspective to a message passing perspective, a return to
> object-oriented programming – which most current Java, Scala, Groovy, C
> ++, Python, Ruby, etc codes that I have seen do not employ.
It's just one of several possible solutions, and is a good fit for a great
many problems. It's also VERY widely employed within Scala via the Akka
framework.
> Go and Groovy/GPars, and others, are trying to alter this. Immutability is
> critically important, the question is at what scale. Functional
> programming, actors, dataflow, CSP, all have slightly different
> architectural views on this.
Again, these are ALL techniques available within Akka. My personal
favourite is to use an asynchronous model akin to node.js (although with
multiple threads), which I've found to be blazingly fast (no mailbox
overhead) and which also interoperates with actors very cleanly. So I can
mix and match as the architecture demands, switching paradigms effortlessly.
I know that GPars also offers many of the same constructs, but found that
Akka has made these things a great deal more composable by taking advantage
of Scala's for-comprehensions, and consciously sticking to the Monad
contract. (loosely speaking, a monad is anything that supports the map,
flatMap and filter operations). I've also found it far easier, with Akka,
to mix different styles in the same codebase.
> The core issue is surely to remove
> shared-memory multi-threading as the main applications programmer tool
> of concurrency and parallelism. After all locks are designed exactly to
> stop parallelism
100% total and utter agreement.
The next challenge is to then also remove as many blocking operations as
possible, and so turn it up to 11 :)
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
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.
