Thread: Why is functional programming not more popular in C++?

Originally Posted by MutantJohn

The STL seems like it's heading that way too (std::transform, std::for_each, lambdas).

There's your answer right there.
C++ strength is in its ability to adopt your paradigm of choice; not through the language core, but by the expedite use good libraries (standard, or not).

Originally Posted by MutantJohn

Why is functional programming not more popular in C++?

Some constructs are very popular in C++, as illustrated by the standard library. And Boost adds a number of other good ones. They are all used extensively, I'm sure, by those who are aware of their purpose and find a use case for them. C++11 in fact only standardized a subgroup of what has been a longtime practice in C++.

However, the problem with the high level functional constructs is that they'll seduce you into thinking they are the best pattern for a given problem, when sometimes other approaches may be simpler and easier to manage. You can observe this on programming languages that more tightly integrate functional programing with other paradigms. For instance, the excessive and often made-complicated use of such constructs as list comprehensions, maps and lambdas on Python, being one of the most common anti-patterns in this language despite all the advise floating around.

There's a sharp distinction that must be made between a program being executed and a program being developed. A program being executed doesn't care how it is being executed, as long as its purpose is achieved and its requirements are met. For this reason, a developer should always code their programs knowing that they will never be executed, but they will always be maintained.

Function objects and sentinels can take the role of monads in almost all cases you'll come across. On those cases, introducing an explicit monad pattern in your code is hard to justify in a non-pure functional programming language; it offers no practical runtime advantage and comes at a maintenance cost that may not reflect on you presently but will reflect on you in the future when you get tired of monads (and you will!), or anyone else who needs to read your code and become familiarized with an alien pattern to the programming language. Like so many other high-level constructs (in functional programming and elsewhere), the choice of whether these constructs are acceptable should be made based on how well they fit the very structure of the problem being solved and the rest of the problem domain. Unfortunately, because software analysis is a dying art, decisions are made ad-hoc that then need to be carried on to other parts of the program which didn't need the complication.

For instance, the excessive and often made-complicated use of such constructs as list comprehensions, maps and lambdas on Python, being one of the most common anti-patterns in this language despite all the advise floating around.

This line really stuck out to me. I'm surprised that something like a list comprehension or a lambda would be considered an anti-pattern.

I do agree, though, about the monadic pattern being an over-complication in most cases.

Because in spite of not being the latest hipster rage, sentinel values are easier.

This made me lol.

Function objects and sentinels can take the role of monads in almost all cases you'll come across. On those cases, introducing an explicit monad pattern in your code is hard to justify in a non-pure functional programming language; it offers no practical runtime advantage and comes at a maintenance cost that may not reflect on you presently but will reflect on you in the future when you get tired of monads (and you will!), or anyone else who needs to read your code and become familiarized with an alien pattern to the programming language. Like so many other high-level constructs (in functional programming and elsewhere), the choice of whether these constructs are acceptable should be made based on how well they fit the very structure of the problem being solved and the rest of the problem domain.

This is also really, really good advice.

Someone wrote a Validator functor in JS and I have been using it as a means of object validation. This convenient for a couple of reasons. The first, the JSON blob looks identical on both sides (client and server) so the same validation routines can apply to both cases. Second, it aggregates errors when you use it properly.

But using it in a useful context is pretty cumbersome and introduces some very needless overhead. It's not like performance is an issue but I think you might be right about it being a type of anti-pattern. I think I should revisit that code because while I really do enjoy the error aggregation, it isn't the most maintainable solution around and definitely needs to be looked at again.

Originally Posted by MutantJohn

I'm surprised that something like a list comprehension or a lambda would be considered an anti-pattern.

Mario F. referred to "the excessive and often made-complicated use of such constructs", but unless the normal and reasonable use of such constructs tends to have overall negative consequences, they are not anti-patterns in themselves. At best you can say that such poor usage is an anti-pattern, but I don't think that's the right usage for "anti-pattern".