4 ms·

To be fair I think the same is true of procedural languages. Parallel computation often requires some sort of coordination mechanism, and there are more failur

by Tobani 11y ago

To be fair I think the same is true of procedural languages. Parallel computation often requires some sort of coordination mechanism, and there are more failure modes. Functional languages often lend them selves to elegant mathematic-looking functions and algorithms with many of the dirtier parts figured out by the compiler. In order to map algorithms to parallel computing for non-trivially parallel problems you'll need things like futures, message passing, etc. that gets you back into specifying the dirtier low-level parts of the algorithm again. Its more idiomatic in a procedural language because your'e doing all of this work all the time any way. It is still a hassle, it just doesn't mess with the "Elegance."

pdpi 11y ago
Have you ever looked at Strategies (or the Par monad) in Haskell? To me, Strategies exemplify some of the stuff you can do with functional languages that are _really_ hard to achieve elsewhere.
- Tobani 11y ago
  I have seen it before and it is pretty amazing. My comment was mostly in context of the 2003 message. People are finding more and more clever ways of handling this all the time. Par(at least monad-par on hackage) seems to have come around 2011. Really multi-core machines have only been standard for about 10 years now? Before then, multi-processor machines filled more niche roles (Servers, HPC, etc). Now my phone has 4 cores. Parallel computing is becoming more common because all of the code you write will run on a multi-core system. I definitely see how writing multi-threaded code in a lisp in 2003 would have been less savory. Things are definitely better now. Things like Par & Repa can do some amazing things in Haskell. I'm sure there are more some great packages out for scheme that are similar . I don't think we're 100% there yet. Who knows where we'll be in another 10 years?
bunderbunder 11y ago
Even stuff that can be handled by futures and message passing feels relatively trivially parallelizable to me. Anytime you've got a problem that can be decomposed into distinct subcomponents that only need minimal contact with each other you can keep most the real nasty concurrency issues swept under the carpet. And the functional stuff still feels like it works fairly well to me because it's easy enough to model all the different subcomponents as more-or-less idempotent operations on the elements of a message stream. The spot where I'm finding that functional programming just cannot help me is when I really do need to have all the cooks in the same kitchen to get good performance. Those situations exist in a world of highly refined, weapons-grade side effect, and the only thing to be done for it if you find yourself there is to come to terms with that fact and get on with your job.

by Tobani 11y ago

pdpi 11y ago

Have you ever looked at Strategies (or the Par monad) in Haskell? To me, Strategies exemplify some of the stuff you can do with functional languages that are _really_ hard to achieve elsewhere.

Tobani 11y ago
I have seen it before and it is pretty amazing. My comment was mostly in context of the 2003 message. People are finding more and more clever ways of handling this all the time. Par(at least monad-par on hackage) seems to have come around 2011. Really multi-core machines have only been standard for about 10 years now? Before then, multi-processor machines filled more niche roles (Servers, HPC, etc). Now my phone has 4 cores. Parallel computing is becoming more common because all of the code you write will run on a multi-core system. I definitely see how writing multi-threaded code in a lisp in 2003 would have been less savory. Things are definitely better now. Things like Par & Repa can do some amazing things in Haskell. I'm sure there are more some great packages out for scheme that are similar . I don't think we're 100% there yet. Who knows where we'll be in another 10 years?

bunderbunder 11y ago

Even stuff that can be handled by futures and message passing feels relatively trivially parallelizable to me. Anytime you've got a problem that can be decomposed into distinct subcomponents that only need minimal contact with each other you can keep most the real nasty concurrency issues swept under the carpet. And the functional stuff still feels like it works fairly well to me because it's easy enough to model all the different subcomponents as more-or-less idempotent operations on the elements of a message stream. The spot where I'm finding that functional programming just cannot help me is when I really do need to have all the cooks in the same kitchen to get good performance. Those situations exist in a world of highly refined, weapons-grade side effect, and the only thing to be done for it if you find yourself there is to come to terms with that fact and get on with your job.