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

So, working in a heavily JS-based environment, I've grown accustomed to functional-based approaches.

My question is, why aren't functional patterns more popular in C++? I'm reading the wiki page on monads right now because I'm determined to implement the Maybe monad just for fun this weekend and I'm just thinking, why isn't this done more?

I think C++ is probably the best candidate to realistically carry functional programming right now. It's type system and C++11 features makes it realistic to implement and the advantage with C++ is that it allows you to eschew the functional paradigm when the OO or imperative ones would do well.

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

Quote:

---

Originally Posted by MutantJohn

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

---

I dunno, my C++ has a lot of functions in it, most of the time it's quite functional...

Quote:

---

Originally Posted by MutantJohn

My question is, why aren't functional patterns more popular in C++?

---

A lack of enforceable tail recursion is a pretty serious drawback, and as much as I love RAII, lifetimes being fixed to blocks also presents a serious conflict.

Quote:

---

Originally Posted by MutantJohn

I'm reading the wiki page on monads right now because I'm determined to implement the Maybe monad just for fun this weekend and I'm just thinking, why isn't this done more?

---

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

Quote:

---

Originally Posted by MutantJohn

I think C++ is probably the best candidate to realistically carry functional programming right now.

---

Is it? In my experience, it's much nicer to use the features you speak of in Lisps and Haskell.

It looks a little bit ugly in C++ and you end up writing a lot of code for nothing.
(Also, without lazy evaluation, a lot of the interesting idioms do not translate properly.)

Consider a 'textbook' example, in Haskell you could express Quick Sort like this:

Code:

---

quicksort [] = []
quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
  where
    lesser = filter (< p) xs
    greater = filter (>= p) xs

---

(Disclaimer, this is not a 'production ready' sort you would normally use in Haskell, but it looks beautiful and is sufficient for small cases.)

Now you could, in theory, write a similar version in C++ but a normal array version looks better and is orders of magnitude faster.
This might improve in future C++ standards with some variant of lazy ranges, though!

Quote:

---

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).

Quote:

---

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.

Quote:

---

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.

Quote:

---

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

---

This made me lol.

Quote:

---

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.

Quote:

---

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".

That's interesting. As an aside, here's an implementation of a Just (partially). I'd welcome any pointers/tips on it.

So, because I'm still relatively inexperienced, when Mario said, we write code for maintainability, are monads/FP approaches really just more trouble than they're worth? I could easily see how some monad stuff would confuse other developers. It also makes bringing additional coders to the team _that_ much harder. *sigh* Sometimes they make sense but even when I'm explaining it to people I'm just like, man, this _is_ confusing.

Okay, I'm done wasting my time implementing FP stuff! I found this: GitHub - beark/ftl: C++ template library for fans of functional programming

There's already this massively awesome library out there. Okay, so functional programming _can_ be done in C++ and it doesn't seem like the worst thing ever.