Objected oriented programming became popular because a skilled software engineer could create an application outline/spec and then pass that on to lower skilled

Objected oriented programming became popular because a skilled software engineer could create an application outline/spec and then pass that on to lower skilled programmers who would implement the spec without completely fucking it up. It made it easy to separate out work among large teams and write tests (ok we are going to divide up the work between these implementations, each of which gets its own set of unit tests for each function) and standardized some of the high level interactions ahead of time (see: convert spec to code). It was never meant to be a surgical scalpel that a highly skilled developer could use to attain high individual productivity. Also I highly disagree with the assertion that "Data structure and functions should not be bound together". I would argue that if you are using any sufficiently complex or niche data structure that is not part of some standard library or a primitive, you absolutely do want to bind functions to the datastructure. It is much better to define a data structure with a set of logical human-readable functions for what you want to do with it than to keep it as some collection of primitives or standard lib datastructures you pass around everywhere. Let's say you are writing a spell checker. You really want to abstract away all the ugly details of the trie and any other helper datastructures. You also may want to create an interface for some "word library" that you can extend with different solutions to test e.g. performance (if you are trying to optimize for caching). Object oriented programming really simplifies things in a scenario like this.