My point was procedural STYLE coding is no better or worse than OOP STYLE coding. The bottom line is really who is using the tool and how their using it.

You say that OOP improves maintainability and ease of adaptation, I say that good design and coding techniques are more responsible for improved maintainability and adaptability than the tool chosen to implement the solution. Certainly some tool architectures lend themselves to greater functionality, quicker development cycles, and ease of use but doesn't it all really come down to how you use the tool?

Your comments that OO concepts and practices are complex and that may be the reason MS hasn't implemented it in VB and that we all are paying a price for the continued support of Backward Compatibility in VFP. Isn't the backward compatibility in VFP there for exactly this reason ? I always thought it was there so it was easier to "port" old applications and leverage some existing knowledge while you come up to speed on the new technologies. I don't think it forces you to do these things or use old techniques its just there if you want it.

On the "having six dozen ways to do things" may very well complicate the interpreter but as this is a interpreted language and we have no control over the included run-time classes I rather like having the ability to attack a problem several different ways while coming to the same or similar solution. Its that individuality thing.

You feel that OOP has given you advantages with its implementation and I feel the same way, however its not the end-all or only way to go.