5 ms·

Some of the practical aspects that favour functional programming lies in parallelism, not concurrent programming. Parallelism as in multi threading. It's an ord

by deepGem 10y ago

Some of the practical aspects that favour functional programming lies in parallelism, not concurrent programming. Parallelism as in multi threading. It's an order of magnitude easier to write parallel programs in Scala than in Java. I don't mean a simple hello world but real world applications which will involve transactions and potential deadlocks. Agree Yes, the parallel constructs in Scala work with Java threads underneath, but you write a lot less code. I don't think Functional programming makes any task easier. In fact I'd argue the opposite, it's quite difficult to write functional code, to unlearn imperative programming. Once you gain mastery over FP, you do write less code. Reaching that level of mastery is an uphill task, it has been for me at least.

jackmott 10y ago
So there are some domains where that parallelism easing can really work out well, when dealing with jobs over thousands of cpus, or gpus etc. It can however get almost comical in the case of desktop/single server applications, where you have maybe 4 or 8 cpus available. Because you can write something nice in F# or Scala, and run it on 4 to 8 threads, get a nice speed up. But the same code, written in an obvious manner in C, ends up auto-vectorized and/or auto paralellized to some degree and runs ~8x faster on just one core. Could be more, of much less, depends on many factors, but it is something to consider. This isn't an inherent problem, but most functional languages need a lot of compiler/JIT work to make the parallel features a net performance win more of the time.
- galacticpony 10y ago
  Not to mention that there are much better libraries for data-parallel programming available for C/C++, plus there are languages designed for data-parallelism (OpenCL, ISPC) and they're not functional either. Untold amounts of energy (and dollars) must have been wasted on the "convenience" of writing some program in Python that scales over cluster of MapReduce nodes, without investigating how an in-core solution in a straightforward native implementation would have performed.

by deepGem 10y ago

jackmott 10y ago

So there are some domains where that parallelism easing can really work out well, when dealing with jobs over thousands of cpus, or gpus etc. It can however get almost comical in the case of desktop/single server applications, where you have maybe 4 or 8 cpus available. Because you can write something nice in F# or Scala, and run it on 4 to 8 threads, get a nice speed up. But the same code, written in an obvious manner in C, ends up auto-vectorized and/or auto paralellized to some degree and runs ~8x faster on just one core. Could be more, of much less, depends on many factors, but it is something to consider. This isn't an inherent problem, but most functional languages need a lot of compiler/JIT work to make the parallel features a net performance win more of the time.

galacticpony 10y ago
Not to mention that there are much better libraries for data-parallel programming available for C/C++, plus there are languages designed for data-parallelism (OpenCL, ISPC) and they're not functional either. Untold amounts of energy (and dollars) must have been wasted on the "convenience" of writing some program in Python that scales over cluster of MapReduce nodes, without investigating how an in-core solution in a straightforward native implementation would have performed.