Edsger Dijkstra carried computer science on his shoulders (2020)

Composition has been used since LISP I and ALGOL 60 in almost all programming languages.

"Separating interface from implementation" is also the main feature of the programming languages based on abstract types, starting with Alphard and CLU, which are not OOP languages and which predate the time when Smalltalk has become known to the public, launching the OOP fashion.

An abstract type is defined by an interface, i.e. by a set of functions that have arguments of that type and this is a programming language feature that is completely independent of the OOP features like member functions, virtual functions and inheritance.

All OOP languages have some kind of abstract types, though with a different point of view on the relationships between individual objects and types a.k.a. classes and the functions that operate on them, but there have been many languages with abstract data types without the OOP features.

Moreover "separating interface from implementation" has also been the main feature of all programming languages based on modules, starting with Mesa, Modula and Ada.

The features that identify an OOP language are the idea that the functions belong to individual objects, not to types, hence the member functions, the substitution of the union types (of the right kind, like in Algol 68, not of the pathetic kinds encountered in Pascal and C and derived languages) with virtual functions (to provide an alternative form of dynamic polymorphism, which is preferable for closed-source software, by allowing changes without recompilation, unlike with tagged unions where there are select/case/switch statements that must be recompiled when the union is extended), and the inheritance in a class hierarchy.

There are many languages that are multi-paradigm, like C++ or D, where you can choose whether to write a program in an OOP style or in a totally different style, but there are also languages where it is difficult to avoid using the OOP features, or even impossible, because all the available data types may be derived from some base "object" type, inheriting its properties.

We can be thankful that this applied physicist in particular decided to dedicate time to think carefully about the needs of who would be his colleagues and successors, when he was pretty much inventing programming as a profession; he told of the anecdote of when he got married, and he wasn't able to write in "programmer" as his occupation in the Dutch paperwork, because it didn't exist as a job category yet.

We are talking about the person that institutionalized the "we people aren't smart enough to do X" line of thinking from software engineering.

Of course, he was also quick to call a spade a spade, but I haven seeing any case of him denouncing something that wasn't obviously bad.

I spend 90% of my time formulating descriptions of the problem and the desired end state

Hallucinating futures where the state of the world is in a state that I either wanted to be or that somebody’s asking me to build

Once you know your final end state, then you need to evaluate the current state of the things that need to change in order to transition to the final state

Once you have your S’ and S respectively then the rest of the time is choosing between hallucinations based on sub-component likelihood of being able to move from S to S’ within the time window

So the process is to basically trying to derive the transition function and sequencing of creating systems and components that are required, to successfully transition from state S to state S'

So the more granular and precise you can define the systems at S and S' then the easier it is to discover the likelihood pathway for transitional variables and also discover gaps, where systems don't exist, that would be required for S'

Said another way: treat everything - both existing and potential futures- as though they are or within an existing state machine that can be modeled. Your task is to understand the markov process that would result in such a state and then implement the things required to realize it.

The religious call this "Prayer"

Others call it "Manifesting"