Sun has a large group led by Guy Steele working on a language called "Fortress" -something they describe as "Java for scientists, Java for the programmers of a peta-scale supercomputer."
Java started out as a hardware abstraction layer for set top TV boxes aimed at using the TV to provide internet access and became wildly popular because people thought the same abstraction could be effectively applied to reduce the impact of Microsoft's perpetual client changes. That turned out, eventually, to be sort of true - but only if Java first moved onto the server and that, of course, drove its strategic role at Sun. Great, but since Microsoft doesn't have a presense in super computing, there's no need to build a Java like kludge there.
This isn't to say that there isn't a niche for a new programming language aimed at helping scientists make better use of super computers, there is. Right now that niche is filled mainly by Fortran and C, or C++, at the traditional applications level and Maple and Mathematica at the desktop level.
I've used both Fortran and C fairly extensively, and tried both Maple and Mathematica under Solaris as recently as last year. Of these C seems ridiculously undervalued these days, Fortran was obsolete in the sixties, and both Maple and Mathematica are so absurdly PC centric in everything they do that they're not worth a nickel for work big enough to need a Unix workstation.
I've recently been trying to understand, however, how to build an application that would make truly effective use of the four way threading in Niagara's cores to get from 11Ghz (8 cores x 1.4 Ghz) to 44.8 (32 x 1.4) on chunks of C and C++ code. As part of the digging around that's occassioned, I came across a comment Donald Knuth made about APL in a 1993 interview with Dan Doernberg
DD: I realize your current emphasis is on "literate programming", but were you ever whatsoever attracted to APL as a math-oriented language?Knuth: That's another story. APL is for people who have problems to solve and don't care too much about efficiency; they want a nice elegant way to state the solution to their problem, but the solution that they come up with is not necessarily anything that a computer has an easy job doing. It's a problem specification language, but not a system programming language... .
That's a wicked response - but it's also quite reasonable in the context of the time.
On the other hand, it's dated - those hardware limitations are long gone. Even in 1993, a 32MB APL workspace was worthy of comment. Today a Sun V890z workstation can deliver nearly 64GB of real workspace and a virtual infinity of memory mapped virtual space for less than two hundred thousand bucks - and tomorrow's Niagara and Rock systems will bring those costs down to the affordable desktop level.
So what's wrong with APL? it fits Sun's CMT like a glove, is easily understood and used by the science community, and allows for simple results publication and verification. For real problems you'd need a petaflop machine, but so what? That's what they're building.