On Tue, Nov 18, 2014 at 7:37 PM, Gavin Lambert
On 19/11/2014 14:32, Vladimir Batov wrote:
While I agree with your point I suspect there might be something more fundamental why functional programming in C++ and functional programming in general has been on the fringes of and hardly present in mainstream commercial s/w development (not academia).
The main problem I think is just that functional programming is more restrictive. At least in pure FP, your functions can only see their own inputs and provide values by their direct outputs. Most "real" code is messier than this -- you end up with containers of things and operations on those things that may have side effects and working state, and often end up hanging things off singletons.
I feel like it's a little bit different from that. I say this because "functional" algorithms in C++ aren't usually functional in the sense of purity anyway -- they still generally operate via side-effects. Using things like the standard algorithms do not preclude any of those "real" scenarios. What we do have plenty of in C++ are high-order functions. Pure functional programming aside, people just seem to not like high order functions in general, regardless of whether or not there are side-effects. My personal interpretation of this is that people don't like them because they add another level of abstraction, or more specifically, a level of abstraction that is /visible/ in their code. Even though we are software engineers and should embrace abstraction, many programmers don't like it because abstraction introduces one more level between what they write and what they get. This is often interpreted as additional complexity as opposed to a tool that helps isolate it. In my opinion, that view of things is a common misconception that sits in the mind of a lot of programmers out there. My overall thought is that the general lack of acceptance of high-order functions and abstraction is mostly just a knee-jerk reaction to that perceived complexity, and this is something that somehow needs to change in the programming community. The following is obviously anecdotal, but in my personal experience, people will hate on something as simple as a high-order for_each function to no end for being too abstract or for obfuscating things, but as soon as it becomes a built-in language feature, such as range-based-for, even if it does essentially the same thing, people immediately embrace it. Maybe it's because it's syntactically "cleaner," but I suspect that's not really it. So what is it then? Again, I don't think it has anything to do with purity since a library-based for_each isn't even generally pure. Again, you can still operate via side-effects. Purity isn't the problem. As far as I can tell it's that if the for-each algorithm is clearly visible as a /function/ and not simply some built-in part of the language, people perceive the notion as somehow more complicated, even though both facilities may do exactly the same thing and with the same amount of abstraction. The avoidance of the library-form stems from a programmer's [correct] fear of complexity that they now erroneously associate with a library-level algorithm even though they wouldn't associate it with a language-level version of that very same, simple algorithm. People ultimately want a solution to be as simple as it can be, for good reason, but I think it's easy to confuse complexity with abstraction and so people immediately look at an abstract, high-order function as intrinsically complex. The difference in perception of the complexity and abstraction between the language-level construct and the high-order library form of the same construct, in my opinion, purely psychological. People just need to recognize this and get past it, though in practice that seems like a difficult step to take and many programmers sadly don't ever take it. I see this as a huge problem because as software engineers, while we should always avoid complexity, abstraction is one tool that helps /remove/ complexity in high-level code by isolating invariants and by representing common patterns as individual high order functions. When people turn away from high-order functions, I generally see it as turning away from abstraction, and that is no way to build large-scale software. Anyway, I have a bad habit of typing a lot of words, but I really feel strongly that this is all very important in "real" development. High-order functions aren't merely academic, they are important for isolating complexity in real-world problems. -- -Matt Calabrese