Fold and map are beautiful, but they work just as well in the guise of a foreach loop.
It's hard to argue with the foundation of the article -- namely that for any novel programming paradigm we've seen implementation of key features in a lot of modern languages, but if this statement holds you could easily say "foreach loops are beautiful, but they work just as well in the guise of an array and an iterative loop in assembly." It's true they produce equivalent results, but the nice thing about (perhaps the whole point of?) higher level languages is that they provide the compiler/interpreter with more clues about the intent of the code, and the compiler can do smarter things because of it.
With map, and i assume fold, you could (in theory) replace the uniprocessor foreach style implementation with a multicore friendly version or even a hadoop/google mapreduce style cluster-aware implementation. If the code was initially in foreach style it would seemingly only be possible if the compiler was smart enough to ensure that there was no access outside of the foreach code block.
I suspect that the premise is right -- that the functional languages of today are probably not going to ever win out over the popular languages of today -- but I think the popular languages of today are going to have to evolve a lot to become the popular languages of the multi-core tomorrow, and a lot of that evolution will come from these functional languages.
Exactly. And not only does map() imply that you can extract as much parallelism as possible, it also means you can access the memory in the most efficient way possible rather than implicitly sorting into the order of the loop counter.
It's hard to argue with the foundation of the article -- namely that for any novel programming paradigm we've seen implementation of key features in a lot of modern languages, but if this statement holds you could easily say "foreach loops are beautiful, but they work just as well in the guise of an array and an iterative loop in assembly." It's true they produce equivalent results, but the nice thing about (perhaps the whole point of?) higher level languages is that they provide the compiler/interpreter with more clues about the intent of the code, and the compiler can do smarter things because of it.
With map, and i assume fold, you could (in theory) replace the uniprocessor foreach style implementation with a multicore friendly version or even a hadoop/google mapreduce style cluster-aware implementation. If the code was initially in foreach style it would seemingly only be possible if the compiler was smart enough to ensure that there was no access outside of the foreach code block.
I suspect that the premise is right -- that the functional languages of today are probably not going to ever win out over the popular languages of today -- but I think the popular languages of today are going to have to evolve a lot to become the popular languages of the multi-core tomorrow, and a lot of that evolution will come from these functional languages.