4 ms·

Parallelism currently is just a nice bonus - say, I lose 3x performance by not detailing a great execution path manually in C++; but I gain 3x performance since

Parallelism currently is just a nice bonus - say, I lose 3x performance by not detailing a great execution path manually in C++; but I gain 3x performance since most of the code is trivially parallelizable to run on 4 cores. Parallel extensions have been (and are being) added to OOP languages to make it's use not only simpler, but even as a preferred general design.

PeterisP 14y ago
In order for such extensions to work on most of my code well, my code needs to written in an FP-inspired style that many new additions to OOP languages do - like C++11, python, etc. As a crude example - there is a big conceptual difference between a for-loop that processes all the elements in a list or array, and a map operation to all the elements in it. The for-loop specifies that the execution will be sequential and in a specific order, so it can't really be parallelized automagically. The map-loop says that it might not be such, so you cannot (a) use a mutable state such as counter incrementation inside; and (b) use the 'previous item' in the calculations. But in practice, you can write most computations in both of these ways - and if you switch from 'idiomatic C' for-loops to map operations (and the equivalents for the many other common data processing tasks), then code is much more parallelizable both in FP and classic OOP languages. BUT - it means that much of your code needs to be written in FP-style even if the language is not FP, so you need to think in FP-style. If you use these "parallel extensions" and the new "preferred general design of OOP languages" then much of your code will be stateless and w/o sideeffects; much of your code will look quite different than classic/idiomatic code that the OOP langage had earlier.
- spikels 14y ago
  Thanks for the explanation. Popular "modern" languages like Javascript, Ruby or Python already have many of the "FP" features mentioned in the OP and comments: first class functions (though not so simple Ruby) and high level data processing functions (e.g. map, filter, select). As best I can tell the big new benefit of FP is the potential, generally not currently realized, for automatic parallelization. The cost is having to think in a new way that is, at least initially, somewhat confusing. Alternatively non-FP languages could simply import ideas from FP and gain the benefits in an evolutionary way. For example if Mads wanted to he could rewrite the Ruby interpreter to have map, filter and many other methods automatically use multiple cores. Eventually programmers using the new multi-core version would learn which structures were, such as map, or weren't, suc as for loops, going to be parallelized. There would be many language specific details to work out. For example determining if there are truly no side effects in a particular situation. This is not always so simple in non-FP languages but still not as complex as analyzing every possible for..end loop. As 4, 8, 16, 32 and more core processors become more and more common the pressure to either change to FP languages, incorporate FP feature in non-FP languages or find some other parallelization methodology (?) will become irresistible.

PeterisP 14y ago

In order for such extensions to work on most of my code well, my code needs to written in an FP-inspired style that many new additions to OOP languages do - like C++11, python, etc. As a crude example - there is a big conceptual difference between a for-loop that processes all the elements in a list or array, and a map operation to all the elements in it. The for-loop specifies that the execution will be sequential and in a specific order, so it can't really be parallelized automagically. The map-loop says that it might not be such, so you cannot (a) use a mutable state such as counter incrementation inside; and (b) use the 'previous item' in the calculations. But in practice, you can write most computations in both of these ways - and if you switch from 'idiomatic C' for-loops to map operations (and the equivalents for the many other common data processing tasks), then code is much more parallelizable both in FP and classic OOP languages. BUT - it means that much of your code needs to be written in FP-style even if the language is not FP, so you need to think in FP-style. If you use these "parallel extensions" and the new "preferred general design of OOP languages" then much of your code will be stateless and w/o sideeffects; much of your code will look quite different than classic/idiomatic code that the OOP langage had earlier.

spikels 14y ago
Thanks for the explanation. Popular "modern" languages like Javascript, Ruby or Python already have many of the "FP" features mentioned in the OP and comments: first class functions (though not so simple Ruby) and high level data processing functions (e.g. map, filter, select). As best I can tell the big new benefit of FP is the potential, generally not currently realized, for automatic parallelization. The cost is having to think in a new way that is, at least initially, somewhat confusing. Alternatively non-FP languages could simply import ideas from FP and gain the benefits in an evolutionary way. For example if Mads wanted to he could rewrite the Ruby interpreter to have map, filter and many other methods automatically use multiple cores. Eventually programmers using the new multi-core version would learn which structures were, such as map, or weren't, suc as for loops, going to be parallelized. There would be many language specific details to work out. For example determining if there are truly no side effects in a particular situation. This is not always so simple in non-FP languages but still not as complex as analyzing every possible for..end loop. As 4, 8, 16, 32 and more core processors become more and more common the pressure to either change to FP languages, incorporate FP feature in non-FP languages or find some other parallelization methodology (?) will become irresistible.