| Well, as I said above, I write games, where we need deterministic runtime behavior, memory, and high speed. Very few other domains get as complex, too. When I said "poke into another object" above, I didn't mean literally mutate the data of another object. Private data is a good thing. I meant grab onto a handle to the object and changes its state through its public interface. None of the "complex" problems you're talking about hit that level for me; they're mostly the kind of algorithm you can easily approach from multiple directions. Pathfinding, ticket price calculation with a million special cases -- these are broad-but-shallow problems for the most part. A spam filter is one or more algorithms applied to a data stream. I don't know Jane Street's OCaml stack, and a quick Google isn't explaining it to me, but it looks like some kind of parser? A game might use pathfinding, but an A-star or one of the many newer algorithms is pretty straightforward. Not the kind of complexity I'm talking about. I'm talking about needing to deal with the state of a hundred or a thousand items that have various ways they can interact with each other and that are expected to have emergent behavior. Like you'd find in games, but as you may also find in stock analysis (speaking of a domain where speed can be critical). I've avoided the worst of OOP I think because I've avoided enterprise work, except for one greenfield project where I got to create an app for the retail space -- and I ran into some pretty awful code that was wrapped in a giant black box that only ran on Windows and required about 160Mb of RAM per user...to run a cash register. No I'm not exaggerating. It was insane. The problem with using concurrency in FP is that the entire point of concurrency is speed, and on the problems that most need speed you get more out of an imperative language. There was an attempt to code an image convolution algorithm in Haskell that I read about. A PhD tried his hardest to parallelize the algorithm and beat the speed of C code handling the same problem. I turned out to be impossible; the asymptotic speed of the Haskell code as you added cores never ended up faster than the C code on one core. Amdahl's Law is a hard limit for a lot of problems. [1] [1] https://en.wikipedia.org/wiki/Amdahl%27s_law |