Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> I have yet to encounter a single mutable variable.
> However, it is constantly poking at a database, and different modules communicate with each other asynchronously over a message queue.
I think you found your mutable variables...
No, I agree, functional programming on its own is not a panacea. Every program has state, even functional programs. FP promotes modeling state implicitly, by representing it in the program text itself (or more precisely, the "continuation" of the program). The evaluator of the program is responsible for managing that state, rather than the program author themself(^).
The problem is that, since the state is implicit, it becomes hard for multiple modules of the program to collaborate over that state. There are ways around this -- for instance, have each module supply descriptions of the changes they want to apply, and have a central authority manage the actual state -- but you ultimately end up with some way to "address" the state, either explicitly or by reference to an entity that owns it. In either case, you have the "address" of some thing that may change over time, and so you've got yourself a mutable cell.
All this to say that FP is indeed not a panacea -- every system needs to have a clear data model. Not only the structure of the data needs to be understood, but also the ways and means in which it is allowed to evolve over time. (Something something Linus Torvalds and Fred Brooks something flowcharts vs. tables something data vs. code.) It sounds like the system you're grappling with has a very loose data model -- I'm not surprised it isn't navigable.
But the core idea I at least take away from FP -- that explicit state should be avoided -- is still vitally valuable, even if you approach it differently in different environments and for different problems. "Out of the Tar Pit" is a wonderful exegesis of the idea. [1]
(^) Does singular "they" become "themself" or "themselves"?...
[1] https://github.com/papers-we-love/papers-we-love/blob/master...
> So the big win with functional programming is easier testibility and fewer hazards when trying to multi-thread your code.
To give you my experience: during my phd, I developed https://ossia.io in C++. For the manuscript redaction, I rewrote all the core algorithms in pure functional OCaml. When I did some tests, performance was slower than -O0 C++ (so it's not even a given that multithreaded OCaml would outperform single-thread C++), the tests weren't meaningfully simpler to write, and it would be pretty much impossible to have an average comp. sci. student contribute to the code.
My experience multi-threading C++ code is, "slap cpp-taskflow, TBB, RaftLib" or any kind of threaded task system and enjoy arbitrary scaling. Hardly the pain it is made to be unless you have a need to go down to std::thread level, but even then using something like https://github.com/cameron314/concurrentqueue to communicate between threads makes things extremely painless.