I find most discussions of this nature to be completely missing the point. Semantic arguments about the specific syntax required to accomplish some goal, or comparisons of which approach works better for a _single_ given use case are silly. We get it, the expression problem exists. The fact of the matter is that FP and OOP work on different levels. Higher-levels favor FP and lower-levels favor OOP. That is, coordination is best-implemented via FP and enforcing rules is best-implemented as OOP. Arbitrarily choosing a single approach ensures poor system design.
For example, as many have pointed out, methods like "collide" or "attack" don't really make sense to have on a single object. This is because this method works at the level of coordination, and therefore _should_ be functional. Alternatively a method like "addDamage" method works at the domain level were it enforces rules/state change.
We can easily apply the above observation to system architecture and conclude that the outer-most layers of an application (services) are best-implemented using a FP approach and the inner-most layers (domain) are best-implemented using OOP.
It does not surprise me that most applications adopt FP. Because most people think procedurally and start applications with a top-down mindset, the outer-most layers (use cases) tend to be modeled first where a FP approach makes sense. This then just carries through the rest of the application.
> It does not surprise me that most applications adopt FP. Because most people think procedurally and start applications with a top-down mindset, the outer-most layers (use cases) tend to be modeled first where a FP approach makes sense. This then just carries through the rest of the application.
Did you mean "OOP" instead of "FP" here? First, I think more applications adopt OOP than adopt FP. Second, I find it hard to go from "most people think procedurally" to "therefore they wind up at FP".
I did not. Simply using objects does not mean one has adopted OOP. OOP means modeling behavior _with_ data, not _around_ data. It is something that must done be intentionally, not a product of your choice of language (although can certainly play a factor).
I would suggest that most systems adopt a procedural style where objects are more or less bags of data being passed around to functions/methods. This generally fits the mental model of how people think. That is, in terms of input -> output. OOP blurs that simplicity because each unit of behavior (method) also has a surrounding context (properties) that may be affected as well.
At the end of the day the difference between Object.DoSomething( data ) and DoSomething( object, data ) is just semantics (look at how python implements classes for example).
For example, as many have pointed out, methods like "collide" or "attack" don't really make sense to have on a single object. This is because this method works at the level of coordination, and therefore _should_ be functional. Alternatively a method like "addDamage" method works at the domain level were it enforces rules/state change.
We can easily apply the above observation to system architecture and conclude that the outer-most layers of an application (services) are best-implemented using a FP approach and the inner-most layers (domain) are best-implemented using OOP.
It does not surprise me that most applications adopt FP. Because most people think procedurally and start applications with a top-down mindset, the outer-most layers (use cases) tend to be modeled first where a FP approach makes sense. This then just carries through the rest of the application.