OOP + CF Debate Response

Reading Brian’s tweet this morning, I decided to read more about this whole OOP Debate. Unfortunately, I didn’t really have time, nor the interest to read Marc’s entire post. But I read as far to the point where he comes to the epiphany that CF is not Java and that it can’t handle the same patterns the same way that Java can…um…duh! I thought this was a known fact about ColdFusion / CFML. Rewind many years to the creation of ColdFusion–that was the whole point of coming up with ColdFusion was to have a language that did not require the sheer complexity of languages like C and CGIs to connect to databases. I think for the most part, ColdFusion has always aimed to be easy or easier and less code etc. If you want to program more along the lines of what Java supports and the patterns it uses, then use Java. Seriously. ColdFusion is not Java and it shouldn’t be. It should be what it is and do it well.

With that, here is my comment to Brian’s response to this debate:

I agree with you, Brian, in that his post may have been partly about the aspect you allude to. However, I also feel there is a real frustration in what he is really expressing with OO and CF. I noticed this same type of demeanor with some folks over the years when I strongly worked with CF. I myself have a Java background and as such tried to make CF follow the patterns and paradigms in the way that Java did. At the same time, I also recognized where CF fell short and thus worked with CF in it’s capacity as opposed to trying to get it to fit into the same context that Java is in.

With that, I encouraged other folks who worked with me to learn the better structured concepts of OO and MVC patterns and using the right mix of frameworks, such as a MVC, ORM, and IOC framework. The problem is, if you don’t understand these concepts from a fundamental level from the beginning without ever mixing CF in, they can be very overwhelming and start to crush the positive attitude that a CFML programmer may have.

Much of the time I also felt that parts of the community were pushing the use of so many patterns it was ridiculous and I think this is the storm that perhaps Marc was feeling.

To reiterate, I do feel that what you mentioned could be an underlying tone and perhaps fueling of anger and frustration, but at the same time I know from other CFML developers that I used to work with, his feelings at that show on the surface are valid and understood.

I think that most of the expert CFML developers in the community know and understand the limitations of the technology. Keep in mind, however, limitations is defined by what the requirements of a project are. Projects’ requirements should be written around the technology being used. Perhaps ColdFusion doesn’t have limitations in the sense of the word when it comes to “industry standard patterns”. From it’s beginning, it has always defined it’s own set of patterns that work for the CFML workflow. Developer’s need to understand to not try to redefine something that doens’t need to be redefined. If they have different needs in a project that are strong enough to fully set the project’s scope outside the circle of ColdFusion, then they need to choose a different technology.

CF continues to have a strong closely-knit community, something I have always enjoyed about it. Embrace the community, but don’t forget that at the end of the day, it’s up to you how you want to program your applications. And yes patterns are good, but don’t overdo it. Allow yourself to focus on the tasks at hand as well as having good design at the same time. True, not EVERYTHING needs to be “OO”.

Finally, change rarely comes at the perfect time. As web developers, the past 5 years or so have been changing very rapidly with new languages, patterns, frameworks, libraries coming out every day it seems. Don’t focus on being up to date on every single one and figure out how you can use each of them in your next project. Pick and choose what you want to learn and learn it well. In a time such as now, stick with what you know cause you need to hold on for a little bit longer, there are some rough winds up ahead.

I’m serious when I say don’t redefine something that is not meant to be that in the first place. I always uphold innovation in it’s highest regards, but there is innovation and then there is redefinition. They are NOT the same thing, so stop!