4 ms·

this post seems misinformed. in a massively multicore world, parallelism is more important than concurrency, and the two are not the same. basically concurrency

this post seems misinformed. in a massively multicore world, parallelism is more important than concurrency, and the two are not the same. basically concurrency means the order of tasks is not known a priori. parallelism means segmenting a problem so subproblems can be solved in many places at once. in a massively mutlicore world, i offer parallelism is the goal these people want to address. how they did not mention haskell is beyond me.

blasdel 18y ago
None of these people care about scaling anything but the attention they're paid
meredydd 18y ago
in a massively multicore world, parallelism is more important than concurrency, and the two are not the same I think you're right in a technical sense - parallelism is indeed the great goal, and that article used the term slightly sloppily. However, the degree of parallelism in a program is limited by the ability of the human author to cope with all the concurrent interactions. So fundamentally, the two boil down to the same problem. One approach - that taken by Erlang and (from what I understand) Haskell - is to force people to write programs in a special way (pure message-passing or pure-functional), such that they become (almost) embarrassingly parallelisable. Another approach - that taken by Scala, and my personal favourite, Clojure - is to keep the existing paradigm (JVM threads in both those cases), and encourage people to write large parts of their program in styles which make concurrency easier (Actors, STM, immutable values, and so on). There's something to be said for both approaches: Erlang- or Haskell-style "purity" keeps you well-behaved, and gives you a lot more parallelism "for free". On the other hand, there are processes, tasks and other systems which are fundamentally sequential or mutable, and forcing you into conceptual backflips to cope with this can grate. I don't mean to put one approach above the other - and I'm aware that my summary is woefully inadequate - but I do believe it's a valid debate this article is engaging with.
meredydd 18y ago
in a massively multicore world, parallelism is more important than concurrency, and the two are not the same I think you're right in a technical sense - that article used the term slightly sloppily. However, the degree of parallelism in a program is limited by the ability of the human author to cope with all the concurrent interactions. So fundamentally, the two words boil down to the same problem. One approach - that taken by Erlang and (from what I understand) Haskell - is to force people to write programs in a special way (pure message-passing or pure-functional), such that they become (almost) embarrassingly parallelisable. Another approach - that taken by Scala, and my personal favourite, Clojure - is to keep the existing paradigm (JVM+threads in both those cases), and encourage people to write large parts of their program in styles which make concurrency easier (Actors, STM, immutable values, and so on). There's something to be said for both approaches: Erlang- or Haskell-style "purity" keeps you well-behaved, and gives you a lot more parallelism "for free". On the other hand, there are processes, tasks and other systems which are fundamentally sequential or mutable, and forcing you into conceptual backflips to cope with this can create pointless friction. I don't mean to put one approach above the other - and I'm aware that my summary is woefully inadequate - but I do believe this article is engaging with a valid debate, and to pick it apart on sloppy use of a word is to miss the point.

blasdel 18y ago

None of these people care about scaling anything but the attention they're paid

meredydd 18y ago

in a massively multicore world, parallelism is more important than concurrency, and the two are not the same I think you're right in a technical sense - parallelism is indeed the great goal, and that article used the term slightly sloppily. However, the degree of parallelism in a program is limited by the ability of the human author to cope with all the concurrent interactions. So fundamentally, the two boil down to the same problem. One approach - that taken by Erlang and (from what I understand) Haskell - is to force people to write programs in a special way (pure message-passing or pure-functional), such that they become (almost) embarrassingly parallelisable. Another approach - that taken by Scala, and my personal favourite, Clojure - is to keep the existing paradigm (JVM threads in both those cases), and encourage people to write large parts of their program in styles which make concurrency easier (Actors, STM, immutable values, and so on). There's something to be said for both approaches: Erlang- or Haskell-style "purity" keeps you well-behaved, and gives you a lot more parallelism "for free". On the other hand, there are processes, tasks and other systems which are fundamentally sequential or mutable, and forcing you into conceptual backflips to cope with this can grate. I don't mean to put one approach above the other - and I'm aware that my summary is woefully inadequate - but I do believe it's a valid debate this article is engaging with.

meredydd 18y ago

in a massively multicore world, parallelism is more important than concurrency, and the two are not the same I think you're right in a technical sense - that article used the term slightly sloppily. However, the degree of parallelism in a program is limited by the ability of the human author to cope with all the concurrent interactions. So fundamentally, the two words boil down to the same problem. One approach - that taken by Erlang and (from what I understand) Haskell - is to force people to write programs in a special way (pure message-passing or pure-functional), such that they become (almost) embarrassingly parallelisable. Another approach - that taken by Scala, and my personal favourite, Clojure - is to keep the existing paradigm (JVM+threads in both those cases), and encourage people to write large parts of their program in styles which make concurrency easier (Actors, STM, immutable values, and so on). There's something to be said for both approaches: Erlang- or Haskell-style "purity" keeps you well-behaved, and gives you a lot more parallelism "for free". On the other hand, there are processes, tasks and other systems which are fundamentally sequential or mutable, and forcing you into conceptual backflips to cope with this can create pointless friction. I don't mean to put one approach above the other - and I'm aware that my summary is woefully inadequate - but I do believe this article is engaging with a valid debate, and to pick it apart on sloppy use of a word is to miss the point.