Hi, Dan.

Interesting thread. This strikes to the heart of the antipattern I just read about (SET EVANGELICAL ON :-) called "Functional Decomposition" by Brown, et. al. in AntiPatters: Refactoring Software, Architectures, and Projects in Crisis. (SET EVANGELICAL OFF :-). They say:

"Functional Decomposition is good in a procedural programming environment. It's even useful for understanding the modular nature of a larger-scale application. Unfortunately, it doesn't translate directly into a class hierarchy, and this is where the problem begins."

Some of the consequences they point out include the inability to take advantage of inheritance and polymorphism and little hope of software reuse. There's more...It's an anti-pattern I succumb to all the time. Now, they are specifically talking about the abuse of method code, but I believe it is similar to using procedural code in place of class design.

Really you touch on an age old problem of expediancy ("easier") vs. long term viability. What is "cheaper" today, usually ends up costing 3 times as much in the long run. While we do live in the real world and compromise our principles every day (well, maybe not all of us!) it's no good denying that nature of these compromises, is it?

P.S. Every positive point you apply to PRGs is also valid for classes...