I hear a lot of OOP fans say that OOP makes large applications "easier to maintain", and the question always comes to mind "Easier for whom?". If I ask "Who will be maintaining my application?", the answer is "ColdFusion developers", and if I ask "Which programming paradigm are ColdFusion developers generally more comfortable with?", I would have to say the answer is "Procedural". Here in the Orange County/Los Angeles area, it's hard enough to find a decent CF developer without limiting my search to the small amount of people that claim to be OO programmers (and some of those aren't even really OO programmers, they just need a job and will say anything). Not to mention that the CF Developers that really do know OOP are often more expensive than their procedural counterparts.
I am not an OOP guru, so my opinion may not be firmly planted in reality, but I don't think the size of the application really matters when it comes to deciding weather to develop it in pure OO code or to develop it using procedural code and maybe sprinkling in some OO concepts where it makes sense.
I have developed some pretty massive systems, but I don't see how using a pure OO design would have made those applications any easier to maintain. If anything, I think it would have been even more complicated then it already was. It definitely would have slowed down my development (which is not an option for some high pressure, deadline driven, work environments).
I think the most important part of making an application maintainable is making sure that, not just you, but anyone who is proficient with your chosen language will be able to follow the code and understand how it is organized (without having to spend a week or two with Hal Helms to wrap their head around OOP). If, one day, CF developers are all generally more comfortable with using the OO paradigm, and the WACKs are all written so that new CF developers learned how to do OO right from the get go, then I would definitely be on board the OO bandwagon with everyone else, but I just don't see that happening as it would defeat one of the main benefits to programming in ColdFusion: being easy to learn.
I'm not against OOP. If I were developing video games or something in Java, then OOP is definitely how I would go, because OOP is the norm for Java developers. Also, I would definitely be open to spending some time fine tuning OOP concepts in my mind by applying them in some ColdFusion sample applications, just because I am already familiar with CF and it would allow me to concentrate my learning efforts on the OOP concepts rather than learning a new language.
However, while I think OOP is good in theory, and there are a lot of ways I use it's basic concepts to improve the way I write my procedural code, I just don't think I'll personally be using a pure OOP approach in real CF applications anytime soon.
I don't think either paradigm is fundamentally better than the other. I just think they are two ways of doing the same thing. In the long run, how you choose to organize your code is up to you, and I believe the general consensus, among OO and procedural programmers alike, is that it is important to keep your code neat, organized, consitant, and wherever possible, you should try to identify parts of your code where you can write generic modules/custom tags/functions/components/objects/etc so that when you need to change some bit of logic, you only need to do it in one spot.
HOWEVER, OOP does allow code reuse among the same application, and that is something that many procedural programmers lose. I have seen hundreds of apps that have thousands of .cfm pages, each with thousands of lines of code, each doing almost the exact same thing. You wouldn't even need OOP, just a few functions, includes, whatever...
Using OOP principles you end up with a consistent API, consistent UI (not guaranteed, but it does help), and maintainabilty.
You stated that it is difficult to find a CF programmer that programs OOP well. The problem that I see is that there are very few CF programmers who know how to program. Period. I sometimes find that since CF has such a small learning curve, people jump into it, call themselves programmers, and write all kinds of terrible apps that give ColdFusion a bad name.
So maybe we don't need to write OOP style code, but I would at least recommend that we know what it is, know the advantages of it (if any), and create goals for ourselves of writing solid code.
Ben Nadel is a great example of a great CF programmer- he knows that he doesn't know everything, so it is his objective to be constantly learning and bettering his apps.
So should OOP be the goal, or should solid, maintainable, commented code be what we are after?
"The problem that I see is that there are very few CF programmers who know how to program"
This is very true, I have hired developers that were "Senior Developers" at other companies for years, and then had to teach them how to not write terrible code anymore, but usually that does not involve teaching them concepts that are foreign to them, just stopping them from writing sloppy code because they are lazy, and forcing them to follow a few rules that ensure things stay organized.
If I had to take those same people and try to explain what Inheritance, Abstraction, Encapsulation, and Polymorphism mean it would be much more difficult.
Solid, maintainable, well documented code is definitely the goal.
I've been in the opposite situation where I was the new CF developer telling the "Senoir(Old) Developer" about doing things "well" instead of in a sloppy fashion. Lets just say my views to do things "well" were frowned upon and the thought of OO scared him silly... so I moved on. I'm not here to fix the world just to code to the best of ability.
Even though I'm an advocate of OO I sometimes wonder about peoples use or I should say overuse of the principles in CF. Even though CF has Objects/components it is no Java or C#. I would really like to see the CF OO language features get a power hit so they are more hardy. CF leaves a lot of weight on the developer to make sure they extend, implement, or override functions/properties correctly. In the end this allows for mistakes to be made in the OO structure. So fingers crossed for the CF9 release being focused on the language like CF6 was.
The number of years someone has been a developer does not indicate the quality of that work experience. There are a lot of people that just move from one maintenance job to another who maybe get good at "MacGyver-ing" existing applications to meet the ever changing needs of their employers, but never actually build an entire application from the ground up. I don't think that means they aren't capable of doing it, but it would be a bit of an eye opening experience for them. It's a lot harder to learn how the differences between different design patterns, frameworks, and programming paradigms, when you are never doing any new development.
I was lucky enough that my first few ColdFusion jobs were positions where I have been the "web-architect", but I have also had the "web-handy-man" jobs and can see how I could have easily fallen into the other category if things had been different.
However, the main point of this post really, is that I don't a lot of the "web-architects" that are over implementing OO in their apps just because they think it will be more maintainable (for them) are really truly thinking about who else might be maintaining this application in the future. Chances are pretty high that a "web-handy-man" is going to come along and jerry-rig your work, and you don't just need to make it as easy as possible for him to do that, you need to make it as easy as possible for the owner of the application to find a web-handy-man that can work on the application. And let's face it, most of the "web-handy-men" out there are more comfortable with procedural code.