The problem is not so much expressing the parallelism (especially data-level parallelism), it's dealing with the consequences- especially the race conditions and deadlocks that result. How do you gaurentee that the function passed into the parallel iter, map, or fold is appropriately reentrant?On Wednesday 23 May 2007 20:27:24 Robert C Fischer wrote:...and locks and threads are not a viable long-term solution to the problem of concurrency in general.Absolutely, that's why we have parallel iter, map, fold etc.
Yep. The advantage of data-level parallelism is that it scales with the amount of data. You can always use more processors simply by throwing more data at the program. The problem is that it is of limited applicability, and that a lot of problems don't fit well (or at all) in it. The advantage of event/message based parallelism is that it is more widely applicable, the problem is that it doesn't scale- if you write your ap with N threads, it'll use up to about N processors- but the N+1st processor will be useless. This is a problem because the current proper formulation of Moore's law is that the number of processors available is doubling every 18-24 months (maybe faster).Functional programming is not a panacea. GUI programming is one application area where functional programming, immutability and the parallelizable constructs that I just mentioned are not so beneficial. To solve GUI programming you need different constructs (events, message pumps etc.).