Perhaps the most serious limitation is the tendency for large procedural-based programs to turn into "spaghetti-code".
Spaghetti code is code that has been modified so many times that the logical flow shown in the figures above becomes so convoluted that any new programmer coming onto the project needs a two month prep-course in order to even begin to understand the software innards.
Why does this happen?
Well, in reality, a programmer's job has just begun when she finishes writing version 1.0 of her software application. Before she knows it, she'll be bombarded with dozens of modification requests and bug reports as users actually get to batter and bruise her poor piece of code.
In order to meet the demands of the evil user, the programmer is forced to modify the code. This can mean introducing new sub loops, new eddies of flow control and new methods, libraries and variables altogether.
Unfortunately, there are no great tools for abstraction and modularization in procedural languages...thus, it is hard to add new functionality or change the work flow without going back and modifying all other parts of the program.
Now, instead of redesigning the work flow and starting from scratch, most programmers, under intense time restrictions will introduce hacks to fix the code.
This gets us to the second problem with procedural-based programming. Not only does procedural code have a tendency to be difficult to understand, as it evolves, it becomes even harder to understand, and thus, harder to modify.
Since everything is tied to everything else, nothing is independent. If you change one bit of code in a procedural-based program, it is likely that you will break three other pieces in some other section that might be stored in some remote library file you'd forgotten all about.
A final problem with spaghetification, is that the code you write today will not help you write the code you have to write tomorrow. Procedural-based code has a tenacious ability to resist being cut and pasted from one application to another. Thus, procedural programmers often find themselves reinventing the wheel on every new project.
Procedural-oriented programming is actually very powerful, so
don't let the hype make you think that it has no place in your
arsenal of programming tools.
Like libraries, languages, and toolkits, methodologies are just ways to solve certain sets of programming problems. There is no such thing as an all - powerful methodology. In some cases, the object-oriented approach will be best suited to your needs and in others, another methodology might be more appropriate.
PS: A well written procedural-oriented program can actually be easy to understand. It is just that well written procedural code is hard to find, especially when 'teams' of programmers, working on multiple versions are involved. The fact is that procedural languages typically lack the syntactic sugar necessary to enforce abstraction.
Greg Smith sent in the following excellent comments...
It was good to see "Limitations of Procedural-Oriented Programming" but spagetti is the result of goto'ing all over the place ("goto"ing, "exit"ing, "leave"ing, "break"ing etc.). The single strand / thread, of control, whatever, is lost.
Programs written without the abortions of logic can be read, understood, debugged, etc. in half the time. (a paper witten back in the 60's was the first recognition of the problem and it outlined the new "structured" approach which from then on has been the known preffered method).
Again, OOP can offer almost the same benefit on top of that . . . if still, the rules of structure, are followed, and not the spagetti of goto's, etc. Unfortunately, all languages still support most, if not all, of the options for making spagetti out of what could have been structured code. just as C++ offers the ability to use OOP methods, but does not require it. (in C the case statement seems to be written so as to nearly require "break"ing)
Basics of structured programming:
Structured code is easier to write, debug, and maintain than the "spagetti" world of goto's, iterates, and exits that preceeded. Once it was discovered, in the early 60's, that the time involved in programming could be cut in half by following the rules given above, there has been no defensible justification for doing otherwise, though "spagetti" persists.
Object Oriented Programming is a methodology that gives great importnace to relationships between objects rather than implementation details. This distinction is important and like Structure above, can make code easier to write and maintain.