I think I agree with what most others are saying, which is, roughly:
- Lord, I hope not.
- But yeah, probably.
The thing is, MPI is a really good middleware for some other language to compile down to; but it's shocking that in 2012 we're still expecting our fellow scientists to write raw MPI calls. And I'm not convinced that it's going to get any better; people worry about writing million-way parallelism with MPI, but (a) they don't suggest an alternative, and (b) you wouldn't do million way parallelism with a flat MPI decomposition; you'd program your 128-core nodes with OpenMP (or MPI-3 on-node communicators, or whatever) and use tradaditional MPI to do 8192-way parallelism across nodes, which suddenly seems not all that daunting. Even if you make it 1024-way nodes and 131,072 of them, which gets you up to 130 million, nothing there is clearly impossible.
The problem is that the magical language that allows you to express parallelism so clearly that it can be efficiently parallelized down to distributed memory for you never materialized. Frankly, at this point I think it's pretty clear that it's not going to happen, and the best we can hope for is domain-specific languages; but even there, I dispair that the "domains" there aren't going to be, say "fluid dynamics" but rather "regular-grid finite-difference"; eg, still the wrong level of abstraction.
Some of the recent attempts have been interesting as in "wow, we learned a lot from that effort" but not interesting as in "wow, let's use that for our next project." The people who work with it think Charm++ is great, and the idea seems good - specify the finest level of parallelism and let the runtime worry about assembling that and locality - but it still seems to me like yet another in a series of frameworks that are "perfectly general" as long as you restrict yourself to considering problems that are well-suited to that kind of framework. Stuff like coarray fortran is certainly better than raw mpi, but not enormously -- you still have to decompose the domain and figure out which sub-domain you need to communicate with, you just don't have to write the message-passing yourself. So that's something, but... UPC is interesting, in that in some ways its more ambitious -- you're just supposed to pretend you're writing a serial code and have the array decomposition done for you -- but bolting those global distributed array concepts onto a language that barely has the concept of 1d arrays, and no concept at all of higher-dimensional arrays, was so obviously doomed to failure that you wonder what people were thinking. X10 is just bizarre; how is a program language where you're manually responsible for doing all the forking and joining of threads going to help you with million-way parallelism? Also, java.
The one that strikes me the most interesting right now is Chapel, but that's probably because I'm still trying to find time to play with it. Chapel seems to have really nice mechanisms for separating the code describing the decomposition of the data from the code describing what you do with the data; and it comes with several very common decompositions "built in". It, more than the others, seems like it's approaching the problem the right way around; letting you re-do decompositions without rewriting all of your code, and having several reasonable decompositions baked in.