I agree to some extent. When I see this in imperative code-bases, it can be used as a way to reduce lines of code and save having to define a new class. But when debugging or trying to make sense of the code it can be awful. However it's not the passing functions to functions that is the problem, it is the division of responsibility not being though through while doing so.
As a silly made up example, you pass a callback to an XML parser to tell you when a node has been parsed, so you can pass in a callback to call an API to let it know. Doing something like that just pollutes the XML parser code for no good reason, and you then debug and find you get a 400 error when trying to parse something and 'wtf' and you have to untangle the callbacks.
I'm having a hard time summing it up right now, but I think if you try to "libraritize" "specific code", i.e. make something that does a very specific job, too generic it causes confusion.
That example has 1 callback but believe me some developers want to stack 'em high.
As a silly made up example, you pass a callback to an XML parser to tell you when a node has been parsed, so you can pass in a callback to call an API to let it know. Doing something like that just pollutes the XML parser code for no good reason, and you then debug and find you get a 400 error when trying to parse something and 'wtf' and you have to untangle the callbacks.
I'm having a hard time summing it up right now, but I think if you try to "libraritize" "specific code", i.e. make something that does a very specific job, too generic it causes confusion.
That example has 1 callback but believe me some developers want to stack 'em high.