It's cool, my friend - just don't insult me.
I must admit that that's true to some extent.
Note the 'potential' qualifier - it implies that people felt that there *might* be problems with procedural programming in the future; not that there were problems at the present.
I respectfully and strongly disagree - C is still being used to write programs, and the language has consistently ranked in the top 5 for the last few years (if not decades). The most prominent and often cited case of a non-trivial program written in C is the Linux kernel - and you might say - yeah, but the decision to use C was made in the nineties; if it were decided now, surely they'd go OOP (i.e. C++). Not so, according to Linus Torvalds - it would still be C! (incidentally, 'git', Linus' other project, is C too).
At the current job, we write software for network switches, and guess what - it's all C without a shred of C++ (thank god).
There is a perception out there that C is obsolete and nobody uses it anymore, which seems to me like a form of delusion induced by the OOP marketing machine.
Oh well - whatever this man says, writes or advocates does not affect my position in any ways; if anything, it makes me more suspicious.
It is this tendency of OOP being revised (refined?) that I take issue with. Ok, so there is this 'inheritance' concept that was developed/discovered. Let's use it! Here's how you use it: <how-to-use-v1>. 10 years later - um, no, actually, that wasnt' right - we got unforseen problems when applied in practice, so let's use it this way : <how-to-use-v2>. 10 years later... See the pattern??
You did notice that the body of an a OOP 'method' is procedural code. So OOP can't be 'better' because it's not a separate thing that would sit at the same level and could be compared. Underlying it is procedural code, so it's more like a layer on top.
So maybe you meant : better than procedural programming *without* OOP added to it? No. Allow me to elaborate :
Suppose we have problem P, and two programs: program O - written in OOP style, and program S written in procedural style. Both programs solve the problem P completely and correctly. Compare the programmatic complexity of the two : program O is composed of procedural code + OOP overhead; program S is procedural only. So program S is *simpler* in structure and complexity. The conclusion follows by the 'simple is better' principle.
I like your analogy, but my argument is more like : if the nails do the job then there's no need for screws.
I would suggest you to read 'Notes on Structured Programming' by E. Dijkstra, but don't read it like a prose - instead read it like a math book :do the exercises, try to get an understanding of the concepts and the proofs. If you are like me, it will give you an appreciation for the beauty, simplicity and power of the ideas presented; it's an eye opener. Then, compare the insights and the clarity of thought you gained, with the fuzziness and flaky concepts that you'd get from the OOP camp. In my opinion - there's no contest.
It's baffling to me that the structured programming paradigm has not had a foothold on the industry as OOP did. I blame it on the marketing machine of OOP (which SP does not have).