Another programmer finds myObject.doExplicitThingToWorld() far more expressive and easy to understand
To me that's not a good enough reason to write my code in that style, when to me (subjective), OOP models the world in a way that is more expressive, I/O is not a thing I need to run scared from, and the methods I write that mutate the world do so clearly enough to me, just in their naming.
> myObject.doExplicitThingToWorld() [is] far more expressive
But if I put the word "than" after that, consider what you would type next. Are you arguing that "myObject.doExplicitThingToWorld()" is more expressive than "doExplicitThingToWorld(myObject)"? Because you could write code like that in the FP world, and it's basically the same as the OO world, except (assuming immutability) you'll also know that myObject is not changed after that call.
But runT1ME is talking about how the FP equivalent would come with more information ("I can see clearly if I'm doing both input/output, (or just output), and I have laws to help me understand how I can compose this function with others").
This added information is not subjective. There objectively is more information. The stuff you conveyed in your OO code by naming a method "doExplicitThingToWorld()" can also be conveyed in FP code by naming a function "doExplicitThingToWorld()", but the OO world misses out on the information that monads bring (and monads are just an example of this).
Sure, saying that "more information is not necessarily a good thing" is true. But are you arguing in favor of having less information? Because in that case, why isn't procedural-style programming better (subjectively) to you? After all, one could make the case that OO pollutes code with unnecessary information (classes and hierarchies) and that just like how FP overhypes composition, OO overhypes inheritance
Yeah the overall win is what's subjective. To many, programming in a functional style, and embracing concepts like 'monads', is not appealing, regardless of that additional information.
There are lots of things we could do to add more information to our programs. We could write tooling that religiously enforces a certain amount of commenting for example. which would be 'more information'. But it's debatable/subjective that adds value overall, given the cost to developers.
> But are you arguing in favor of having less information?
Short answer, no, it's the manner in which it's conveyed, and the hoop-jumping required to do so that constitutes the subjective element.