This came up in another context recently and got me to thinking. One of the interesting things about object oriented design (OOD) is that it generally subscribes quite literally to the principle of res ipsa loquitur which in Latin means "the thing speaks for itself." Tying functions to data structures means that the resulting objects are responsible for how their data can and should be used. This goes well beyond using OOD to create simple designs by reducing the number and complexity of relationships between program components. OOD software architects generally create objects with the intend of making them easy to (re)use for specific programming tasks rather than designing objects to have as little interaction with the rest of the software as possible.
This is very much different than the approach taken in science where the axiom is that the data does NOT speak for itself. Where theory does all the talking and the data is used only to test theory. In science, the same data may fit several different theories. For example, at low speeds and ordinary precision, velocity measurements confirm both Newton's Laws of Motion and Einstein's Theory of Relativity very well. It's only when you have high speed requirements that the theories start saying different things (make different predictions).
I've noticed that Google's Go language (golang) takes this different approach. It is not an object oriented programming language. In Go, you can define a data structure (type) and then afterward associate any number of methods or interfaces to that specific data structure. These methods and interfaces are not intrinsically part of the data's type themselves. A programmer never creates Java-like objects. A different programmer could take the same data structure and define a completely different interface for it.
I call Go's style of programming "elephant" programming. (With apologies to the parable of The Blind Men and the Elephant.) I tend to favor elephant programming in situations where the user requirements can be organized into distinct groups of requirements. Like the blind men feeling different parts of an elephant and interpreting an elephant to be like a wall, a snake, a fan, or a tree trunk. Like when the same software suite will be used in different ways by different groups of people within a company or other large organization. The data structure is often a relational database or even large flat files for many scientific applications. The sets of functions and interfaces embody the different user requirements and comprise what is called the middle-tier in the client-server programming paradigm. Very practical and efficient. Yet nary an object speaking for itself.