The thing is... functional programming has its own version of a lot of these problems, as well as its own problems. The easiest example is the base class fragi

The thing is... functional programming has its own version of a lot of these problems, as well as its own problems. The easiest example is the base class fragility problem. This is just a special case of the compounding fragility of any reusable component, where fragility increases with the width and depth of its dependents. If, instead of a class, a function is reused by many other functions it will suffer the same problem. Any changes to that "base" function will affect all functions which invoke it down the dependency chain. I believe the actual issue is that isolating and defining abstractions from the landscape of necessary implementations is actually very difficult. AKA "programming is hard". I think in a lot of cases it is impossible to correctly model abstractions, since different use cases will push and pull on different parts of the "boundaries" of the given abstraction. In other words, reality is messy and our computer models are usually extremely naive.