Maybe one part of the reason you hate them is that they have been associated with so much marketing bullshit and pseudo-religion. It helps to realize that actua

Maybe one part of the reason you hate them is that they have been associated with so much marketing bullshit and pseudo-religion. It helps to realize that actually there is not one unitary concept of what 'OO' means. You can defeat your object allergy if you stop engaging with people's rhetoric and ideology about objects, and just evaluate particular language features individually. If the same task can be done with a function/sub or with an object, objects typically add two problems: 1. Added boilerplate: before I do work I typically instantiate an object, etc. In many cases it is really obvious that this is just adding pointless lines of code and pointless plumbing. It doesn't help that the big OO languages have accreted so many bad, verbose coders and cargo-cult methodologies, enhancing the extra-boilerplate effect. 2. Unlike locals inside a function, objects' mutable state is accessible in multiple places at multiple times (and merely using getters and setters does not fundamentally change this - and add even more ridiculous boilerplate of the sort which causes people to have gigantic IDEs writing highly repetitive code for them) Here's what you are missing: objects are just a kind of mini-program, with a more flexible interface and execution model than subprocesses. It's a generalization of the subroutine and largely equivalent to a coroutine. Even if that doesn't work for you, they are still handy as 'bundles': e.g. a point in 3-space with x, y, z components AND an attached set of methods for doing normal things like dot products, all passed around together. This isn't necessary, but it can make things neater just like bundling certain wires together into a cable. Evaluate them like 'here is this thing, what can it be used for?' You might decide you like objects, or perhaps just that they have their place.