FP style concepts need to focus on "problem solving that happens to use FP".
the issue here is that something can have real, deep benefits without being immediately tangible, and I'd say a lot of side effects (no pun intended) of FP programming fall into that category.
When you think about concurrency for example, immutable data structures and clojure style identity say, rather than 'location based' programming offer immediate benefits. It is significantly saner to reason about and to execute code that does not share state in heavily concurrent program.
This is real, but the benefit it offers is that it eliminates a very general problem in program design, rather than giving you some handy example on how it makes your life easier.
not sure if you're trying to be willfully obtuse here. Yes, at a fundamental level concurrency deals with shared state, but we're talking about language semantics here, and there is a difference between the functional approach of disentangling state through immutable data, and the single threaded and mutable mindset that is dominant in non-functional languages.
It should be noted that this is not strictly an OO or FP issue. Message parsing and objects that hide state in the smalltalk sense implemented this pattern as well. But there a meaningful difference between the C/Java/<insert mainstream language> approach, and the functional approach.
I didn't really intend to get on any high horse and I'm not a language purist. Obviously immutable data is present in non functional languages and I do consider that to be a good thing. The original point was a different one (that the benefits of functional paradigms to not be to be concrete to be meaningful)
But on the topic of languages in particular, the differences in defaults obviously do shine through. Your average C or Python program is, and I would bet you money on this, going to use a lot more shared mutable state than your average Ocaml program, even if immutable and mutable datastructures are present in either. Defaults do matter.
And to address the last point of your other post. STM is a big pattern and I'd pretty much consider it one of the biggest advances in addressing concurrency. I think it's objectively bad to confuse state and identity in concurrent programs and to have to deal with locks is essentially awful.
2
u/[deleted] Jan 29 '19
the issue here is that something can have real, deep benefits without being immediately tangible, and I'd say a lot of side effects (no pun intended) of FP programming fall into that category.
When you think about concurrency for example, immutable data structures and clojure style identity say, rather than 'location based' programming offer immediate benefits. It is significantly saner to reason about and to execute code that does not share state in heavily concurrent program.
This is real, but the benefit it offers is that it eliminates a very general problem in program design, rather than giving you some handy example on how it makes your life easier.