Wrap Up
Recently I had the questionable pleasure of watching “Cosmic Sin” courtesy of Netflix. The movie is a sci-fi show starring Bruce Willis. I was lured into wasting my time on it, by the trailer promising a space-operish feat and I took the presence of such a star playing in the movie for a warranty on quality. I couldn’t be farther from the truth.
The movie plays out confusingly, lacking a coherent script and motivated actors, pushing the watcher into an undefined state (not UB luckily). The helpless watcher, astonished by how bad a film could be, hopes until the very last for something interesting and entertaining to happen until the mixed relief-disbelief emotion of closing titles puts an end to the suffering.
When thinking about C++ and functional programming I have some of the feelings I had watching the movie. Before being persecuted by my friends from the C++ community I have to make clear that C++ is not that bad, although there are some similarities.
I am confused by the C++ author and the Who’s Who of C++ claiming that C++ supports functional programming paradigm while seeing no real-world, industry-standard support in the language. The current level of support for functional programming in C++ is minimal, marginal, and too rough to be taken seriously. It is not enough to spray some lambda over a C++98 to get a functional language. Moreover, functional principles are ignored all around the library even when constructs could have been made functional at no cost (I’m thinking about std::optional, std::future and std::any, and the lack of immutable standard containers). The ranges part of the standard library (C++20) comes a bit too late and with some impedance mismatch with other parts of the standard library.
In the same way that Cosmic Sin could have been a different movie, C++ could still have been a different language. Sometimes at no cost, as for std::optional and std::future that could have been easily designed with monadic features. For the other parts, since the C++ ISO Committee is made by brilliant language engineers and designers, I have two possible options – either C++ has grown too contorted and complicate to accommodate for proper functional programming support or the committee is just not interested and paid the least possible amount of tribute on the altar of FP gods (meaning barely usable lambda functions).
Possibly the reality is a mix of the two options – C++ has become too contort and complicate (maybe for a reason) and the C++ community is not that sensitive about FP. From what I see, this language community seems to be strictly focused on performances, accepting every kind of ugly construct as long as it lets you squeeze the last drop of performance from the CPU. As long as this could make sense in very specific areas, is not something that makes sense at large where the 95% of CPU time is spent in the 5% of the code, leaving 95% of the code unaffected by performance issues.
For a few years, I did OOP in C. It is a daunting task if you want to do it at the same level of efficiency that C++ does. You need to adopt a number of conventions and stick religiously to them while stuffing your code with macros. Writing real FP in C++ could be that hard, sometimes impossible, but for sure it feels clumsy in much the same way.
My conclusion is that the best you can do today with C++ and FP in industrial-level code is using some FP approaches in an overall imperative code. Write your own monads and immutable containers. Maybe that server-level code could be made a bit more FP since there are plenty of resources and more FP constructs can be simulated by relying more heavily on dynamic memory, but don’t expect to write anything close to Zio or cats-effect.