This is a purely theoretical question about programming.
I would like to know through a simple example (answer with a complement of figures, drawings, etc.), the meaning of two sentences for two types of programming languages:
Not everyone agrees, but it's just a way of thinking that makes little difference in the end.
I do not know where you saw this comparison, but it already starts wrong. Programming structure, contrary to what it may seem is about the algorithm . And the object orientation is about the data structure, it's about the organization of the code . So it does not make much sense to try to counter these two ideas.
The same goes for imperative , which makes a little more sense to counter, but not much. It makes no sense to choose one or the other, they are complement. The object orientation is a secondary paradigm (actually some people consider that orientation is not even a paradigm).
Object-orientation opposition is procedural programming .
From this we can see that much is said about the subject without much knowledge of what it is about. Much less makes sense to separate language in structured or object-oriented. This is simply a wrong concept.
Almost every time people's code is imperative and with some use of object-oriented.
What you probably mean by these phrases is that the most imperative pure code you call actions that will act on data and the code with object-oriented style you take the dice and call an action on top of it. >
Procedural imperative:
substring("abc", 3, 1)
Object-oriented imperative:
"abc".substring(3, 1)
So it ends up being only the first one invoked, the behavior, or the state. Then in the first code the substring() will act on the text "abc" (procedurally it acts on the object), whereas on the second you have the text "abc" controlling access to the code substring() (the object calls the procedure) .
Outside help an IDE to more easily fragment what it can do with the data, it changes very little and it is silly to fight more for one style or another. Object orientation has some advantages as well as disadvantages elsewhere.
This facility is even worse because many people find that it is easy to find the methods that the object can perform does not require you to study the documentation, and it ends up making much worse codes. Worse, for wanting to do what's fashionable anyway, she ends up doing what she does not understand.
It may be useful: