5 ms·

Here's another myth: "Functional programming solves the concurrency problem". http://www.infoq.com/presentations/java-performance http://www.infoq.com/presenta

Here's another myth: "Functional programming solves the concurrency problem". http://www.infoq.com/presentations/java-performance http://www.infoq.com/presentations/java-performance Scroll to 41:05

seanmcdirmid 12y ago
Has anyone ever seriously believed this? I guess it's just easier to coordinate resource sharing when resource sharing isn't allowed. My favorite is "Functional programming is becoming more relevant because...multi-core" so your 100x slower functional code would get a 4x speed up and only be 25x slower?
- tel 12y ago
  I think it's a good step for exactly the reason you suggest. In a world where resource sharing happens uncontrollably it's maximally difficult to design good concurrency. In a world where sharing is totally eliminated, it's trivial to be concurrent but boring. Working back toward greater sharing from the share-nothing viewpoint is a great place to throw effort.
- jackfoxy 12y ago
  Here's another myth, functional code is 100x slower (than what?). Here's the counter example, Microsoft Research chose the functional first language F# to build arguably the most advanced and useful quantum computer simulator in existence. http://research.microsoft.com/en-us/projects/liquid/ http://research.microsoft.com/en-us/projects/liquid/ There's no incentive to rewrite it in C++. It already solves real quantum computing problems like molecule simulation https://channel9.msdn.com/Events/Speakers/dave-wecker https://channel9.msdn.com/Events/Speakers/dave-wecker
  - seanmcdirmid 12y ago
    There isn't anything in this project that implies immutabilty was extensively used for shared state in this case. F# is a pragmatic language, you can do what you want.
- ExpiredLink 12y ago
  > Has anyone ever seriously believed this? Hickey, Datomic?
  - Confusion 12y ago
    Believing you can solve the concurrency problem[1] using functional programming as your tool-shaping method of choice is different from believing functional programming solves the concurrency problem. [1] Whatever 'the' concurrency problem may be and not implying that I agree that the Clojure people believe they can solve it or intend to solve it

Here's another myth: "Functional programming solves the concurrency problem". http://www.infoq.com/presentations/java-performance http://www.infoq.com/presentations/java-performance Scroll to 41:05

seanmcdirmid 12y ago

Has anyone ever seriously believed this? I guess it's just easier to coordinate resource sharing when resource sharing isn't allowed. My favorite is "Functional programming is becoming more relevant because...multi-core" so your 100x slower functional code would get a 4x speed up and only be 25x slower?

tel 12y ago
I think it's a good step for exactly the reason you suggest. In a world where resource sharing happens uncontrollably it's maximally difficult to design good concurrency. In a world where sharing is totally eliminated, it's trivial to be concurrent but boring. Working back toward greater sharing from the share-nothing viewpoint is a great place to throw effort.
jackfoxy 12y ago
Here's another myth, functional code is 100x slower (than what?). Here's the counter example, Microsoft Research chose the functional first language F# to build arguably the most advanced and useful quantum computer simulator in existence. http://research.microsoft.com/en-us/projects/liquid/ http://research.microsoft.com/en-us/projects/liquid/ There's no incentive to rewrite it in C++. It already solves real quantum computing problems like molecule simulation https://channel9.msdn.com/Events/Speakers/dave-wecker https://channel9.msdn.com/Events/Speakers/dave-wecker
- seanmcdirmid 12y ago
  There isn't anything in this project that implies immutabilty was extensively used for shared state in this case. F# is a pragmatic language, you can do what you want.
ExpiredLink 12y ago
> Has anyone ever seriously believed this? Hickey, Datomic?
- Confusion 12y ago
  Believing you can solve the concurrency problem[1] using functional programming as your tool-shaping method of choice is different from believing functional programming solves the concurrency problem. [1] Whatever 'the' concurrency problem may be and not implying that I agree that the Clojure people believe they can solve it or intend to solve it