5 ms·

For a certain (large) class of programs, being "functional" is an advantage. Interestingly, you made the point that being functional means easier maintenance e

by funcall 16y ago

For a certain (large) class of programs, being "functional" is an advantage. Interestingly, you made the point that being functional means easier maintenance etc., but fail to attribute those advantages to being functional. If your argument is that there can be bad functional code which performs worse than non-functional (imperative or OO) code, I don't disagree. However, in the multicore future that our semiconductor overlords have in store for us, functional programming has a demonstrable advantage in helping build understandable and robust programs.

WilliamLP 16y ago
I don't think you should claim "demonstrable" and "future" in the same sentence. "Theoretical" or even "promising", perhaps. The most performance intensive problems in the world, when they have competition, are very much still solved in C and C++.
- funcall 16y ago
  You're quite right about the juxtaposition of "demonstrable" and "future". I should have said functional programming has "already" demonstrated an advantage in producing robust and understandable concurrent programs, which will continue to be relevant in our multicore future. Really, there's nothing "theoretical" about that fact. To your second point, I made no claims that C and C++ are not used to solve performance intensive problems. I'm sure C and C++ (or Assembly, for that matter) can be applied to solve any number of problems, if that's one's calling.
  - cageface 16y ago
    I should have said functional programming has "already" demonstrated an advantage in producing robust and understandable concurrent programs Examples of this other than Erlang?
  - danieldk 16y ago
    Well, what's it worth if you are doing (real-world) number crunching, and your program turns out to be one or two orders of magnitude slower? For instance, after implementing some machine learning software in Scala, I ended up rewriting it in C++, because it was so slow (IIRC the Scala version was 50x slower). The only way you can get down to 'a couple of times' slower is by writing Scala as Java with a slightly different syntax. And since the program does many repeated matrix calculations in a loop, parallelizing the C++ version was done in half an hour (mostly testing where lock contention kills the advantage of parallelization). Yes, I do realize that there are more applications of multicore processing than number crunching ;).
cageface 16y ago
From an interview with the father of Haskell: http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell http://www.infoq.com/interviews/armstrong-peyton-jones-erlan... But it turned out to be very hard to turn that into actual wall clock speedups on processes, leaving aside all issues of robustness or that kind of stuff, because if you do that style of concurrency you get lots of very tiny fine-grained processes and you get no locality and you get very difficult scheduling problems. The overheads overwhelm the benefits, in short. It may be true that FP does make concurrency easier, but I don't think this has been demonstrated to be generally true yet and it's certainly not as simple as just eliminating side effects from your code.
- neilc 16y ago
  It may be true that FP does make concurrency easier, but I don't think this has been demonstrated to be generally true yet Perhaps not generally true, but I think MapReduce and LINQ are two prominent examples of how a "functional programming-like" model lends itself to easy parallelization and distribution.
  - danieldk 16y ago
    And there are also enough 'prominent examples' for impure imperative languages. For instance, OpenMP makes parallelizing some loops in C/C++ a walk in the park, and I have parallelized some of my programs by adding only a few pragmas. The 'FP makes concurrency easier' is a often-used selling point, but I think the jury is still out. First of all, many functional languages are impure, and do not have this advantage in the same manner that e.g. Haskell has. Second, purity can be an expensive trade-off due to the copying involved. For lots of things (e.g. fast linear algebra) you'll still want to work in an impure world. I think a better selling point of some functional languages is clarity. For instance, some class of problems can be solved very elegantly in Haskell and ML using algebraic data types, pattern matching, etc. But then again, some other classes of problems can be solved elegantly in Prolog.
    - neilc 16y ago
      And there are also enough 'prominent examples' for impure imperative languages. For instance, OpenMP makes parallelizing some loops in C/C++ a walk in the park, and I have parallelized some of my programs by adding only a few pragmas. I'm curious -- were the programs that were easily parallelized with OpenMP largely data parallel to begin with? I haven't used OpenMP extensively, but I'd suspect that the ease of parallelizing a program with OpenMP probably varies inversely with the amount of explicit coordination/synchronization/update of shared state that the program requires.

by funcall 16y ago

WilliamLP 16y ago

I don't think you should claim "demonstrable" and "future" in the same sentence. "Theoretical" or even "promising", perhaps. The most performance intensive problems in the world, when they have competition, are very much still solved in C and C++.

funcall 16y ago
You're quite right about the juxtaposition of "demonstrable" and "future". I should have said functional programming has "already" demonstrated an advantage in producing robust and understandable concurrent programs, which will continue to be relevant in our multicore future. Really, there's nothing "theoretical" about that fact. To your second point, I made no claims that C and C++ are not used to solve performance intensive problems. I'm sure C and C++ (or Assembly, for that matter) can be applied to solve any number of problems, if that's one's calling.
- cageface 16y ago
  I should have said functional programming has "already" demonstrated an advantage in producing robust and understandable concurrent programs Examples of this other than Erlang?
- danieldk 16y ago
  Well, what's it worth if you are doing (real-world) number crunching, and your program turns out to be one or two orders of magnitude slower? For instance, after implementing some machine learning software in Scala, I ended up rewriting it in C++, because it was so slow (IIRC the Scala version was 50x slower). The only way you can get down to 'a couple of times' slower is by writing Scala as Java with a slightly different syntax. And since the program does many repeated matrix calculations in a loop, parallelizing the C++ version was done in half an hour (mostly testing where lock contention kills the advantage of parallelization). Yes, I do realize that there are more applications of multicore processing than number crunching ;).

cageface 16y ago

From an interview with the father of Haskell: http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell http://www.infoq.com/interviews/armstrong-peyton-jones-erlan... But it turned out to be very hard to turn that into actual wall clock speedups on processes, leaving aside all issues of robustness or that kind of stuff, because if you do that style of concurrency you get lots of very tiny fine-grained processes and you get no locality and you get very difficult scheduling problems. The overheads overwhelm the benefits, in short. It may be true that FP does make concurrency easier, but I don't think this has been demonstrated to be generally true yet and it's certainly not as simple as just eliminating side effects from your code.

neilc 16y ago
It may be true that FP does make concurrency easier, but I don't think this has been demonstrated to be generally true yet Perhaps not generally true, but I think MapReduce and LINQ are two prominent examples of how a "functional programming-like" model lends itself to easy parallelization and distribution.
- danieldk 16y ago
  And there are also enough 'prominent examples' for impure imperative languages. For instance, OpenMP makes parallelizing some loops in C/C++ a walk in the park, and I have parallelized some of my programs by adding only a few pragmas. The 'FP makes concurrency easier' is a often-used selling point, but I think the jury is still out. First of all, many functional languages are impure, and do not have this advantage in the same manner that e.g. Haskell has. Second, purity can be an expensive trade-off due to the copying involved. For lots of things (e.g. fast linear algebra) you'll still want to work in an impure world. I think a better selling point of some functional languages is clarity. For instance, some class of problems can be solved very elegantly in Haskell and ML using algebraic data types, pattern matching, etc. But then again, some other classes of problems can be solved elegantly in Prolog.
  - neilc 16y ago
    And there are also enough 'prominent examples' for impure imperative languages. For instance, OpenMP makes parallelizing some loops in C/C++ a walk in the park, and I have parallelized some of my programs by adding only a few pragmas. I'm curious -- were the programs that were easily parallelized with OpenMP largely data parallel to begin with? I haven't used OpenMP extensively, but I'd suspect that the ease of parallelizing a program with OpenMP probably varies inversely with the amount of explicit coordination/synchronization/update of shared state that the program requires.