Sometimes, you can improve your code by having it return a description of what to do, rather than doing the thing directly. This is like in SQL where you might return a query plan, rather than executing a query. Once you have this description, or plan, you can analyze, transform and inspect it before passing it to some execution engine that actually does the work.
(https://www.youtube.com/watch?v=GqmsQeSzMdw&feature=emb_logo)
Sometimes, you can improve your code by having it return a description of what to do, rather than doing the thing directly.
...which requires you to turn functions into data structures and then interpret those.
Meanwhile, in OOP land you have objects, which can be seen as self-interpreting data structures.
Thus, saying "let me explain this to OOP developers" is highly ironic.
If that's not clear, let's go back to your description:
>Sometimes, you can improve your code by having it return a description of what to do
Every object is (or at least should be) "a description of what to do" in the exact sense you're using here. This is crucial to understand for properly using OOP.
Maybe not, but it absolutely was part of the original vision. This is why Smalltalk 80 implements if/else statements and loops as methods, rather than keywords. A boolean in smalltalk is not just a value. It's a latent algorithm for choosing between two blocks of code at some later point in time. It's also a latent algorithm for operating on other booleans via binary logic methods. Until you start seeing objects this way, you will not be able to appreciate the elegance of object-oriented programming.
Here are some examples of how this can work in non-trivial scenarios:
I think you may have missed the point. In most OOP languages, an object exposes some capabilities (methods that can be called, properties that can be read, etc), but it does not describe itself very well at all. This is why we have RTTI, instanceof etc. to switch on what an object is. Alternatively, we can use the visitor pattern. As the OP states, these are not as elegant as DUs and matching.
Also, if you call that method on the (OOP) object then "it still does the thing" - rather than returning a description of the thing.
The author talks about a different (meta) way of programming where you create data types for all the actions the program should be able to do, then have your functions modify these descriptions, and, as the very last step interpret the description/run the program.
This concept is not OOP.