Your issue is about the concept of "abstraction", not really about paradigms. Indeed also OOP hides imperative code.
Let's put it in another way: the imperative approach exposes you to the implementation of some task. But it doesn't communicate clearly and immediately what's the purpose of your code.
When you find yourself in front of 1000+ lines of imperative code (maybe written by someone else) you'll only see a long block/blob of low-level code (until you decode it). This leads often to lose sight of the "why" or "what" the code is trying to accomplish.
Sometimes you don't even need to know the actual implementation. Often because is crystal clear what the function is supposed to do, or because a simple analysis of inputs/outputs will clarify the operation performed.
In any case, functions/classes/modules etc. are written by someone, so when needed you can dive into the actual implementation. Same for built-in functions: the specs are clear about what they do and how.
So the point here is: the declarative style/code abstract away from low-level stuff (zoom out) so you can understand what's the goal/direction of the code in front of you. But you can always dig into the actual implementation if you need/want.
Good point, though!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your issue is about the concept of "abstraction", not really about paradigms. Indeed also OOP hides imperative code.
Let's put it in another way: the imperative approach exposes you to the implementation of some task. But it doesn't communicate clearly and immediately what's the purpose of your code.
When you find yourself in front of 1000+ lines of imperative code (maybe written by someone else) you'll only see a long block/blob of low-level code (until you decode it). This leads often to lose sight of the "why" or "what" the code is trying to accomplish.
Sometimes you don't even need to know the actual implementation. Often because is crystal clear what the function is supposed to do, or because a simple analysis of inputs/outputs will clarify the operation performed.
In any case, functions/classes/modules etc. are written by someone, so when needed you can dive into the actual implementation. Same for built-in functions: the specs are clear about what they do and how.
So the point here is: the declarative style/code abstract away from low-level stuff (zoom out) so you can understand what's the goal/direction of the code in front of you. But you can always dig into the actual implementation if you need/want.
Good point, though!