The sad reality is that since so many people are only familiar with the strawman version of OOP rather than the real thing intelligently discussing the advantages and disadvantages of these paradigms is very hard.
The sad reality is that since so many people are only familiar with the strawman version of OOP rather than the real thing intelligently discussing the advantages and disadvantages of these paradigms is very hard.
For example, partial evaluation is limited by the fact that parameters need to be ordered a certain way and you can't realistically cover all combinations.
Higher order functions don't enable any kind of useful specialization at all. And of course, all modern OOP languages also support higher order functions, so they are the ones giving you more tools.
As for higher order functions you would write a function that does the 90% and accepts a function parameter for the other 10%.
https://docs.racket-lang.org/reference/procedures.html#%28de... (god links into the racket docs are ugly...)
Surely you see how this doesn't scale, right?
You would need to first write your code, then abstract every single piece of it as a call to a function passed in parameters. Now your function is accepting five different functions in parameters, and calls them.
This is a terrible and impossible to scale way to emulate class specialization.