I've actually started preferring the `action(subject, object)` form of programming which OO in C entails, rather than `subject.action(object)`. The latter is certainly easier for discovery via auto-complete (with most current tooling).
OO is not a natural way of programming. Everything always starts simply with functions that take arguments. Then you have a function that calls another function with some of the old arguments and some new ones.
Most people go: let's make the shared param an instance var.
The problem with a class, is that every method of the class potentially depends on every other member of the class. What usually happens is that stuff is added to the class that doesn't make sense. And every class needs a noun to name it. Then you have to think what is the proper name for this abstract thing you don't even know what it is yet. Which leads to all these quirky class names that are unnecessary.
If you are explicit about what data dependencies each function has, it becomes easier to see the commonality that should be extracted into classes. Most people just shove everything in a class too soon. And most languages push you to use classes and methods...which usually look very different to how functions are represented.
I completely agree with this. When designing classes it is very easy to get carried away and incrementally add bits to the class instead of passing dependencies explicitly.
Arguably even config is too much and generally functions should only take the subset of config.
In the end this is more art than engineering: classes allow encapsulating all state that needs to be used by all functions together; but as you start making exceptions you'll end up with the mess you describe. The art is finding the right balance between what goes in a class and what should be a standalone (possibly generic) function. Personally, I'm still far from mastering that art.
There is definitely an art to it at some point, but I see a lack of tools to be a big problem.
We are in the stone-age of programming at the moment.
I think the solution is visualization.
I want to click on any variable, and see its full data-dependency graph. All the functions it flowed through and all the transformations that occurred all the way back to a single source of truth.
With this in hand, I think it would be much easier to understand how to group methods and state. We should write code such that this data-dependency graph is easily understood by humans.
That is quite a bold claim. Can we define what is a "natural" way of programming? From my experience you are exposed to one or many programming paradigms and then, when required, you pick the one that works best for you, your problem or your team.
I still see value in modeling some particular problems with OOP and let the underlying model do the heavy-lifting. I know that under the hood every `subject.action(object)` has it corresponding `mangled_action(subject, object)`.
By the way, in our culture, the first exposure we have to functions as children is through infix operations: +, -, *, /. I would not say it is "natural". Prefix and postix operations are not "natural" either. You pick which one works best for you.
I guess I mean that it's not the first thing people reach for unless they know about it. They have some data and want to write a function to do something.
But yeh its probably a too broad statement not worth debating on definitions.
OO is not a natural way of programming. Everything always starts simply with functions that take arguments. Then you have a function that calls another function with some of the old arguments and some new ones.
Most people go: let's make the shared param an instance var.
becomes... The problem with a class, is that every method of the class potentially depends on every other member of the class. What usually happens is that stuff is added to the class that doesn't make sense. And every class needs a noun to name it. Then you have to think what is the proper name for this abstract thing you don't even know what it is yet. Which leads to all these quirky class names that are unnecessary.If you are explicit about what data dependencies each function has, it becomes easier to see the commonality that should be extracted into classes. Most people just shove everything in a class too soon. And most languages push you to use classes and methods...which usually look very different to how functions are represented.