Well this link tries to explain something I've used over the last two decades.
I mention it because it's provably useful and I think it counts as a paradigm, because to use it you need to think in a particular way.
The different way you have to think is that when analyzing a problem, rather than asking what objects there are and what actions take place, you start with the overall requirements and ask What Needs to be Said?
From that, you choose or design a domain-specific-language (DSL), and state your problem in that language.
That link explains a particular language for describing dynamically changing dialog user interfaces. Its implementation depends on a particular control structure, Differential Execution. What it accomplishes is an order of magnitude reduction in source code, with fewer chances for coding errors. Those savings can then be spent in making the UI more sophisticated.
For other kinds of problems, other control structures are appropriate, but the concept of working through a well-chosen DSL, making source code much smaller, more easily modified, and less error-prone, is the common approach.
I think the paradigms of functional programming and OOP are best evaluated by identifying the types of problems for which they are the best expression. Often these paradigms simply become bandwagons and are touted as cure-alls, rather than classifying them by the problem spaces they address.
