Here's another myth: "Functional programming solves the concurrency problem".
http://www.infoq.com/presentations/java-performance
Scroll to 41:05
Pissed off about functional programming (2005)
31–40 of 65 posts
Re: Pissed off about functional programming (2005)
#32I don't quite get why the 'Substitutability' code snippet fails? Is it because the both vars 'point' to the same RAM address initialized with '3'? If that is the case, I would argue the language is somewhat broken, or at least it`s a major caveat ... Please explain?
Don't think about RAM. Instead, consider something like the mathematical expression
x = 3 = y
Of course, in Perl `x` isn't really a variable but instead a name referencing a "slot" which can be mutated. That mutation breaks the reference and makes `x` hold more meaning than merely a "reference to 3". So then you cannot substitute it for `y` any longer.
I think his example code snippet is a little obtuse, though.
Re: Pissed off about functional programming (2005)
#33Here's another myth: "Functional programming solves the concurrency problem". http://www.infoq.com/presentations/java-performance Scroll to 41:05
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?
Re: Pissed off about functional programming (2005)
#34Earlier quoted context omitted.
"I kind of feel like he was missing out on what pure FP can and does achieve." So what exactly was he missing? When I was programming in FP languages, the process didn't seem all that different from other languages, except generally more cumbersome.
That it's possible to write nontrivial programs using immutable data (see Clojure in particular), which makes debugging highly concurrent applications much much easier. That it's possible to achieve precise control over effects with only a moderate amount of overhead. Look at the perennial debate in Ruby-land over whether you should test at the unit or the integration level. In Haskell that's not a choice, it's clear…
Concurrent access of immutable data is super easy since....no real concurrency is going on. But what about when I need concurrency? One can manage the time with which updates are seen (so it is deterministic), but there are many ways to accomplish this beyond one mutable reference to an immutable world style that clojure seems to promote.
Re: Pissed off about functional programming (2005)
#35I assume this post is here to show us that the stupid argumentation about FP vs OOP vs DWIM have been going in circles forever and we should just stop and get back to work.
Yep, there is no need to choose. I use both.
I think Odersky said something along the lines of "mutate with caution". Sometimes it's just the best way to do things, but with caution.
Re: Pissed off about functional programming (2005)
#36Here's another myth: "Functional programming solves the concurrency problem". http://www.infoq.com/presentations/java-performance Scroll to 41:05
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?
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.
Re: Pissed off about functional programming (2005)
#37Earlier quoted context omitted.
That it's possible to write nontrivial programs using immutable data (see Clojure in particular), which makes debugging highly concurrent applications much much easier. That it's possible to achieve precise control over effects with only a moderate amount of overhead. Look at the perennial debate in Ruby-land over whether you should test at the unit or the integration level. In Haskell that's not a choice, it's clear…
Concurrent access of immutable data is super easy since....no real concurrency is going on. But what about when I need concurrency? One can manage the time with which updates are seen (so it is deterministic), but there are many ways to accomplish this beyond one mutable reference to an immutable world style that clojure seems to promote.
Do you have some concrete concurrency use-cases in mind that you could possibly share?
Re: Pissed off about functional programming (2005)
#38To be fair, I've done a fair bit of Clojure and Ruby in my short career, and while it's technically possible to write Ruby code in a Clojure-esque style, it's very ugly and Ruby does not make it very easy. When you write in Ruby, use classes or you will have a headache on your hands!
Re: Pissed off about functional programming (2005)
#39Earlier quoted context omitted.
Concurrent access of immutable data is super easy since....no real concurrency is going on. But what about when I need concurrency? One can manage the time with which updates are seen (so it is deterministic), but there are many ways to accomplish this beyond one mutable reference to an immutable world style that clojure seems to promote.
Do you have some concrete concurrency use-cases in mind that you could possibly share?
Here is something I worked on recently. Let's say you could re-parse code while executing it. A lock is needed so you don't modify a statement list while executing it (you don't want execution to see the partial list). This is where you want one mutable reference to the statement list and then change it completely...so you could use an immutable list at this point. But you could just as well create a new mutable list at this point and save some cycles.
Re: Pissed off about functional programming (2005)
#40"Even a side-effecting function call in C has a well-defined "value" as a state transformer that maps states to pairs of states and values (the so-called "monad" in functional programmers' terminology). The reluctance of functional programmers to call such languages "referentially transparent" merely implies that they are reluctant to admit such complex mathematical/conceptual objects as "values". On the other hand,…
I don't think people who really understand referential transparency would claim that it's impossible to give C a referentially transparent semantics. It's pretty easy. (This essentially feels like looking at the meaning of the language from "the inside" versus "the outside" if that makes sense.) There's a difference between being able to imagine such a semantics and having that semantics be in common and widespread u…
I think this is somewhat misleading. It's easy to give a semantics for a toy C-like imperative language. As far as I know, a semantics that is mostly faithful to the C standard becomes extremely complicated and requires modeling e.g. code layout in memory. The equational reasoning you get from that kind of semantics is terribly weak: essentially, only terms that have the same byte-for-byte effect on memory are really equivalent. So I wouldn't say that exploiting "referential transparency" in Haskell is somehow more obvious, but that it's useful at all.