When I read an article in the Economist about some topic I know a lot about I tend to finish feeling that they've oversimplified a bit. When I read an article elsewhere in the mainstream media about some topic I know a lot about I tend to finish feeling that the reporter had no idea what they were talking about.
That's why I have a print subscription to the Economist.
I only subscribe to one periodical, and it's the Economist. I even get most of my news from there, even if it's a few days old by the time I get to it, because if it's important enough to read about, it won't matter if it's a bit old.
I have the same attitude about the Economist and the New Yorker. Indeed, it's amazing how many of the really big stories of the last few years have broken in the New Yorker, a magazine that gives its reporters months to write stories.
The Economist: one of the few old-school journalism enterprises not to make its way forward by appealing to the lowest common denominator of the potential audience. They go for a smaller audience but can focus much more tightly on what that audience wants: smart, concise explanations of serious issues.
Why is this so surprising? The Economist, like the New Yorker, is famed for its great journalism that covers very wide areas, much wider than Economics, in the case of the former, or the current events in New York, for the latter.
One thing that might help is moving away from event loop based UI interaction, like we see in Windows. One effort in this direction was http://en.wikipedia.org/wiki/BeOS.
http://en.wikipedia.org/wiki/Haiku_(operating_system) seems to have a fair amount of docs on how their API works. Since it is an open source implementation of BeOS it might have some good information. BeOS was made with SMP in mind from word one.
I'm having a hard time guessing the details of how a GUI that doesn't have an event loop in it would work, so I think a more detailed answer would be very interesting.
It is shocking the absence of any mention of OpenCL in the article.
OpenCL could be used either for task parallel(for serial programs and multiple CPUs) or for data parallel(GPUs), and it works really well.
I bet it has more money behind from Apple, Intel, AMD and NVIDIA that ten times whatever MS has invested. (And those companies are hardware companies and know what they are doing).
It's not just new languages, it's new algorithms, most problems aren't trivially parallel.
The problems that are trivially parallel are well suited to be solved by functional/reactive programming via languages like Haskell, Erlang, Scala, F# and Ocaml.
I'm aware of the differences but writing your code in a functional / reactive style makes parallelism much easier.
List.map can be safely parallelized in a functional language where as it cannot in an imperative language. That's what I'm getting at.
In a functional language (lets say haskell) you could switch the implementation of map to a parallel one and the community would probably accept it because there are a few edge cases involving doing something with a monad where it would break but 99% of code would work. If you did the same thing in Java/C/C++/C#/Python/Ruby it would break massive amounts of code.
In theory they have absolutely nothing to do with each other, but in practice they have a lot to do with each other.
That's why I have a print subscription to the Economist.