

Parallel programming is the focus of increasing interest - coolpixar
http://www.economist.com/node/18750706?story_id=18750706

======
Symmetry
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.

~~~
MikeCapone
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.

~~~
podperson
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.

------
kylemaxwell
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.

------
ppod
"“We’re not going to have faster processors,” says Katherine Yelick, a
computer scientist at the Lawrence Berkeley National Laboratory in
California."

Seems a little premature, I wouldn't rule out some big leap forward in
processor technology. Very good article though.

~~~
abi
What factors do you think might lead to a "big leap forward in processor
technology"?

------
tekacs
And appropriately enough the last article published under the topic
'Programming Languages' was published on Apr 3rd 2003.

------
illeto
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.

------
turbojerry
IEEE Software Vol 28 Issue 1 covers Parallelism on the Desktop-

[http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=567250...](http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=5672507)

They even have an article about Intel Threading Building Blocks -

[http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2...](http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fstamp%2Fstamp.jsp%3Ftp%3D%26arnumber%3D5672517&authDecision=-203)

Threading Building Blocks is open source C++ and can be found here-

<http://threadingbuildingblocks.org>

------
bsiemon
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>.

~~~
kristianp
Do you have any info about how BeOS moves away from the event loop?

~~~
bsiemon
<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.

~~~
loboman
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.

------
forgottenpaswrd
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).

------
fleitz
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.

~~~
dons
"Functional/reactive" has a very specific meaning, unrelated to parallelism.

~~~
fleitz
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.

~~~
njs12345
The edge cases would involve unsafePerformIO - you can't use map with
functions in a monad, that's what you have mapM for :)

