Considering CLR & JVM as Manycore Paradigms

Larry O'Brien asks " Are CLR and JVM suited to manycore?" My first instinct is to say no, because they're built on sequential execution and mutable data structures. That said, RPN-stack-based code like IL and JVM opcodes (modulo control flow instructions) is basically an expression graph serialization format, so there's a shadow of hope in there, also considering Expression<T> and friends in LINQ. However, I definitely don't think either of them are in the shape of the end of the road, a suitable UNCOL.

I'm sure you're familiar with Wesner Moise's blog, where he's made some entries relating to the idea of moving away from structures requiring mutability, and towards more functional structures. One recent post that's still in my RSS reader is http://wesnerm.blogs.com/net_undocumented/2006/09/modelview.html, where he hints at some interesting ways of using immutable structures in document / view architectures.

For better or worse, I don't fully share Larry's pessimism (privately related) about functional / dataflow and other "different" ideas. I think we'll see more stratification in the software industry, as people who need the extra performance of parallelism seek out new local development optima, while people who only need current-day levels of performance for tasks that are relatively trivially parallelized (such as today's request/response server code) use other, more procedural languages, like Ruby, C#, Delphi, etc.

IMO, one of the worst things historically to have ever happened in programming was the fashion for C as the "real" programming language. With its primitive strings and its unsafe standard library (i.e. including functions which are literally unsafe no matter which way you call them, consider gets() for example), I think it's wrought unnecessary and disproportionate harm. I hope that any coming stratification doesn't fall into similar social trip-ups that blight us for another few decades.