On Fri, Feb 21, 2014 at 6:08 AM, Kevin Wright <[email protected]>wrote:
> ntel have already released the 15-core Xeon and the 72-core Knight's > landing processors. Concurrency is only getting more prevalent as time > passes, and people need to grasp it by the horns now. > While I can't help but agree with the general idea, I can also say that I want back the responsive systems I recall from the past. I know some of that is rosy glasses, but not all. And this isn't just in the realm of computers, per se. Having suffered through taking pictures with my phone and waiting for the bloody thing to respond to my wanting a new picture is painful. And makes using a DSLR that much more refreshing. Lambdas help, fork/join helps, but these don't go far enough. > You want easy immutability, you want higher-level concurrency models > (STM/async/reactive/actors/parallel collections/etc), you want syntax able > to manipulate and compose functions, If you're dealing with object > hierarchies on the JVM then you want some way (such as pattern matching) to > deal with the expression problem. > Programming techniques today jump to concurrency at a potentially massive expense of memory. Shared nothing architectures are great; when they are in areas that are well known and often actually have real boundaries between systems. Shared nothing architectures in your shared everything system often just leads to slow systems. There has been a dream for ages that the compilers can hide mutability behind immutability. It seems that the gulf between that dream and reality has only widened. Is there good evidence that it is doing otherwise? And actors scare me now more than otherwise. There was an interesting point made in the Akka section of the last coursera class about how Akka seeks to make distributed implementations easy, by making all implementations distributed like. Contrast this with a very salient quote by Torvalds, (apologies on the look of this, not sure the best way to do block quotes in this forum) The fundamental result of access space separation is that you can't share data structures. That means that you can't share locking, it means that you must copy any shared data, and that in turn means that you have a much harder time handling coherency. All your algorithms basically end up being distributed algorithms. And anybody who tells you that distributed algorithms are "simpler" is just so full of sh*t that it's not even funny. Microkernels are much harder to write and maintain exactly because of this issue. You can do simple things easily - and in particular, you can do things where the information only passes in one direction quite easily, but anythign else is much much harder, because there is no "shared state" (by design). And in the absense of shared state, you have a hell of a lot of problems trying to make any decision that spans more than one entity in the system. Obviously, this is from a debate on microkernels and such. I have thus far failed to see how this does not apply to most other items, as well. For an interesting perspective on highly sensitive coding semantics in a codebase, I recommend a current exchange happening in the linux kernel threads.[1] Going off of threads such as we have here, one would think that the kernel should use all of these new techniques. That is, to listen to folks like you, concurrent programming is impossible with locks and other traditional tools. This seems to show otherwise. I am intrigued by the assertion that you either want dynamic typing or heavy typing. [1] https://lkml.org/lkml/2014/2/14/709 -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/groups/opt_out.
