Who the !@$^# is Marc Funaro and What's Wrong With Him???
A recent post by Marc Funaro has stirred up a storm of controversy in the ColdFusion world. You can read it at http://www.advantexllc.com/blog/post.cfm/how-oo-almost-destroyed-my-business. When his blog post was picked up by the reddit crowd, it looked as though Marc might need to enter Witness Protection.
Consider some of Marc's more controversial statements:
- OO ...eroded my confidence to the point of "work paralysis".
- OO took away the very joy of programming it promised to bring...
- ColdFusion applications don't need "objects" and "OO" any more than Coke needs another f#$&*ing flavor.
- OO in ColdFusion is half baked...
Marc talked about a "friend" who -- well, here are his own words:
"I decided to give this all one last shot. My friend, the one from the first training class, was offering a new one... nothing to do with Java. It was "Object Oriented Programming for ColdFusion Developers". This was it. I called my friend, and I told him, 'This Is It. If I don't get this under my belt, I think I need to find another line of work, because this is slowly killing me'
"For almost two months, I remained nearly paralyzed, waiting to go to this class. I was afraid to start EITHER of the two major projects I had lined up, because I was so afraid of the re-writing I might have to do after whatever OO epiphany awaited me. I stalled; I worked on smaller items I could deliver quickly.
"Through fate, I had this friend all to myself for the week. (This was great for me, probably not so great for him.) We laughed, I learned. We talked about something OTHER than programming... often. That alone was therapeutic. I was introduced to a new way of working... a way that was empowering, a way that gave back some joy for all the effort that goes into building a web application."
Sounds great and all, Marc, but conspicuously absent from this meeting with your "friend" is any discussion about the esoteric aspects of OO. Any "friend" who purports to know OO but omits the essential "TriCodalPersificationFlyweightTransferDataObjectBean" sounds a bit suspect.
To repeat my question, "Who is this Marc Funaro guy?", I would have to first answer that he's my friend. Which would make me his friend -- the very one Marc spoke about.
Among the many comments Marc received from his post, several were critical of him. There is some validity to these criticisms: in this post, Marc often paints with too broad a brush. Yet, having observed the CF community both pre- and post-OO, I find myself highly sympathetic with him.
To my knowledge, I was the first person who spoke about the MVC pattern at a conference. Back then, pre-CFCs, OO was some alien idea and preaching OO was lonely work.
But things have changed. Today, OO in the ColdFusion world has become something of a religion. As Marc discovered, it's impossible to say a bad word about OO without one's sanity, intelligence, and motives being questioned.
I find myself in the very odd situation of loving OO -- yet grieving over what OO adoption has done to the CF community. The CF world has split into a relatively small, but highly vocal, cadre of people who "get" OO -- and the vast, unwashed masses who must, like Marc, spend their time working on real projects for real clients.
I say that I grieve because OO can be an empowering technology for developers, but, like so many things, OO is a far better servant than master and, when raised to the position of religion, OO becomes positively enslaving. This is particularly true because OO implementation was done so ill-advisedly in ColdFusion, with each CFC method represented as a separate class in Java. The hit to performance this occasioned has been nearly fatal.
I grieve, too, because so much energy has gone into trying to get ColdFusion to behave as a proper OO language. Forgetting about ColdFusion's true strengths, Macromedia, then, and Adobe, now, have attempted to shoehorn ColdFusion into a Procrustean bed of OO correctness (if I may mix my metaphors). Such was the thinking that brought us to the low point of having interfaces in a dynamically-typed language. Now, Marc fears that trying to integrate Java's wonderful Hibernate ORM will take us farther down the road of lunacy. I fear with him.
But the train to OO-land is on a non-stop schedule. And for what? The "kewl kids", ever on the lookout for the newest thing, long ago left ColdFusion. Ruby, and especially Rails, is the darling of that set -- and welcome to it they are.
Amid the constant drumbeat of "all objects, all the time", real developers have received scant help. It was not Adobe, but a sole developer, Mark Drew, who took it upon himself to create a ColdFusion IDE. For my money, Mark is a real hero and deserves all of our gratitude.
And now, we await Bolt. Will it be the long-awaited IDE that will deliver a world-class ColdFusion editor? Like you, I certainly hope so, but I do so with trepidation. There have been too many promises too long delayed. Even after eight major versions of ColdFusion, the official documentation (or lack of it) remains a scandal in its paucity, incompleteness and, too often, simple inaccuracy.
Meanwhile, the world is moving on. It is no longer any server-side language, but the homely scripting language of the browser, JavaScript, that really does seem to be the future of web development.
As frameworks in the CF world proliferated, I find myself feeling that they have grown too big and too intrusive, causing me to step back from using any of them. Several months ago, a friend showed me a 1200-line XML file needed to manage a persistence framework for a single project. I couldn't help think, then and now, that the cure has become worse than the disease.
When Ben Nadel was struggling to write a relatively-simple application as a pure OO example, he received a surfeit of advice on how to build his application framework stack, and how to build on that to create a robust OO app, but ultimately Ben abandoned the pursuit. It was painful watching. I tried explaining at the time that a class is simply a data type, richer than arrays or strings, of course, but, in ColdFusion, at least, not the end of all things.
We may write off Marc Funaro as a disgruntled "hobbyist" (as one boorish commenter described him), but I think we do so to our own peril. We don't need more hype. I love Java, but we don't need more slavish adherence to Java as the one, true way. We don't need to believe that any silver bullet -- a framework, a design pattern, a paradigm -- will lead us to the promised land of software development success.
Yes, Marc was a bit extreme for my tastes, but I'm grateful that he had the courage to point out that there is a real cost to the mindless pursuit of OO in the ColdFusion world for its own sake, heedless of any measurable benefits.
I wonder if the (vocal) CF community as a whole is undergoing the same process with respects to OO?
You seem to imply at times that those who do OO in CF do so slavishly (somehow thoughtlessly ignoring the performance hit to be one of the "kewl" kids) and they are not working on real projects for real clients (so I suppose the performance hit doesn't matter anyway). Then you imply that it doesn't matter because they are all moving on to greener pastures in Ruby or Groovy anyway (which really is only true of a minority of a minority of well-known bloggers and in many cases just has to do with career changes - not like you have to spend your entire career in CF just to prove something). Then finally this leads you to saying that it all may be of little consequence because the future of the web is a client-side scripting language (which confuses me a bit since that scripting language needs to connect to a server somehow to do anything...yeah there are some server-side javascript products but I don't think that's where you were headed).
First of all, your argument with regard to CF makes no sense. It implies that somehow all the companies adopting an OO architecture have somehow ignored the huge drawbacks only people like yourself have noticed. I know that many of us have spoken at length with Adobe about the CFC performance issue but that really doesn't somehow negate everything else. If so, do you think no one else noticed just to stay "kewl"? Do you think their bosses don't care that their apps are horribly broken because they want their blogger employee to stay "kewl"? The whole argument seems flawed to me unless you mean to say no one is really building apps this way (just talking about it) - which is what you in fact imply.
As for JavaScript, I have been using jQuery a lot (which is your favorite JavaScript framework apparently). I think it has a lot of strengths but I really can't see how its the future of the web. Perhaps I don't have enough experience yet, but compared with working in Flex and passing data via AMF, I feel like I am constantly fighting against parsing strings correctly. I mean the DOM it parses is just flat text which it uses REGEX (though not entirely) to access and manipulate what you want. Fighting with debugging and convoluted selectors just seems like one of those things that comes with the territory...but it makes me think this isn't what we'll all be doing in 5 years. That, though, is more opinion...but its worth refuting that JavaScript being the future of the web is not something many of us buy into.
Several months ago, a friend showed me a 1200-line XML file needed to manage a persistence framework for a single project. I couldn't help think, then and now, that the cure has become worse than the disease.
I know both Reactor and Transfer support the use of includes, so they could have split this into nice manageable chunks very easily. If they had been keen to, they could even have taken a very Hibernat'ish approach and even split it out on a per object basis. That being said, they could have been using a different CF persistence framework, was that the case?
As someone who's jumped back into the cf developer world, Marc's post spoke to me.
I was a cf evangelist at a large fed agency prior to the Macromedia takeover. I brought it in, showed what it could do, taught the masses, and killed 'Notes at every opportunity. Life was good.
Recently reentering the developer world, I stuck with what I thought I knew. And, my initial and remaining impression is that the java geeks have taken over, and that's a problem.
I can still teach whomever cf's strengths. And, I can still get stuff done, and quickly. But, the simplicity of my approach is relatively out of sync with the community's oo obsession.
I now have a relatively difficult answer to why php isn't a better solution, and "why not just write it in java?" wth happened? The experts lost their minds, that's what.
Wanna evangelize oo'ness? Wanna bask in the hack that is ajax? Wanna wallow in oo-pure java? Desperate to progress to RoR? Awesome. Let us know how it turns out.
But, for those of us who've been, and continue to make a living on CF's strengths, let's try to not F' things up beyond what's reparable, 'kay? Maybe it isn't too late.
WTG, Marc. You've spoken for many.
but heres what works for me:
beans representing objects in your business domain (aka your application)
DAOs and gateways for the data layer
service objects that return beans for editing/creating a specific instance of an object (ie a showroom)
and return queries for data browsing (display list of all showrooms)
service objects to populate the database with a bean once the user has filled out a form
and of course a controller layer (fusebox/MG/coldbox) to call the service object and display the form or list
and MXUnit to confirm that your code isn't broken.
THATS KINDA IT!!
Im not seeing why some people find this so hard. I learned this stuff from Brian Kotec's Bookstore app,
it's not rocket surgery, and I bang this stuff out for Dept of State, FAA, whoever every day and we get stuff done and go home at 5:30, no big deal, no drama.....
Hibernate's automatic database schema generation capabilities are the ideal way to do these things. But since we don't have that (yet), I'll happily take my 200 line generator which would require thousands and thousands of lines of boilerplate code to replicate!
And, if you're trying to bring anyone else along, it takes a lot to get them past the fact that they'll be just fine with a few guidelines to ease maintainability and a copy of the ack. I've said, "It works, what's the problem?" Way too many times to people who are doing it right, but think they're doing it wrong.
No one's forcing anything, but the object mania's omnipresent and pretty thick. And do you think that no one could work in groups before oo? Is that really what you're implying? Pardon my bluntness but, do you really think yours is the only way, and that your shop is the only type that'll work?
I'm not slamming Hal AT ALL. I think it's fantastic that he's doing what he can to shed light on an opposing view. Pardon me for agreeing with Marc.
That works for me. I would never be so bold as to tell someone who does not agree with me that they are doing it wrong, or doing a disservice to the CF community or that not using this approach is f-ing things up in CF.
As Brian pointed out, no one is forcing anyone to use an OO approach. Even if your company decides to do so, you have the right to look for other opportunities to not use OO. If a client requires you to use OO, you have the right to go look for other clients.
Persoanlly, I prefer to have the skills and knowledge to be able to code in either environment. It makes me more marketable and more valuable as a developer.
OO is just another tool we have available to us. If you don't want to use it, that is fine, but can we please stop judgng those of us who not only want to use it, but want it improved as well?
You start after me for somehow implying that no one could work in groups before OO. Nowhere in my comment does it say or even imply that. My point was that the only person (besides yourself) who could force you to do OO against your will is your employer. So, if your employer doesn't care about OO *or you are your own employer* and you don't want to learn it, then don't but stop complaining and looking for offense where none is intended.
Second, you complain that no one is writing about non-oo approaches especially for newcomers which comes off as both entitled and misinformed. The WACK books still teach CF in more or less the same way it did back in CF4 (just with new features). I don't recall the WACK books changing to teach purely an OO approach. Secondly, the people who you (and others on Marc's blog comments) complain about writing about OO to the exclusion of procedural approaches have done so freely and on their own. They are not being payrolled by Adobe to do so (and in fact most don't receive any compensation for sharing their learning and experiences at all). So, if you don't like what they have to teach you, don't read their blogs. And if you want to see something else written that no one else is writing, do something about it and write it yourself.
@Brian
I appreciate that you took the time to respond to the points in my post. You're quite right that my argument wasn't particularly linear; honestly, it was more an expression of my frustration than a clear position. But let me try to make it a bit clearer.
Point 1: ColdFusion object performance. Whatever anyone may think of OO, ColdFusion's implementation is faulty. Object instantiation is absurdly expensive. For me, this means that I must take a different approach with CF than I would with, say, Java.
That, in and of itself, is not a particular problem. Different languages have different strengths (and weaknesses). What I perceive to be a very real problem is that OO in CF land has become a religion -- and its adherents ignore the problems with OO in CF. Honestly, when was the last time you read a post talking about the terrible performance of objects in CF and (possibly) proposing a solution?
On the "kewl kids" comments, I was not referring to ANY CFers, but rather the group of developers who are always looking for the next, kewlest thing. This was not a backhanded slight at CFers using Ruby or Groovy. Rather, it was a response to Adobe trying to appeal to that crowd by positioning ColdFusion as a robust OO language. That train has left the station; we're not going to regain the RoRers, so time and money would be better spent at improving the language for those who have valued CF for what it's good at. I agree with Marc that such resources would have been far better spent providing, for example, a world-class IDE rather than leaving it to developers to create.
As for why developers continue to try to make something work (pure OO in CF) that clearly doesn't very well, I think this is probably a question best left to psychologist and sociologists. Here, I'll just say that this seemingly-bizarre behavior of asserting something in contradistinction to the facts is not unknown. Religion is a powerful force in the human psyche and my argument is that OO has been perverted from an enabling technology (one that I have long been and still continue to be a chief proponent of) into a religion. But the facts remain. Take a look at this chart showing the performance of Adobe's CFML engine v. Railo and Open BlueDragon: http://www.railo.ch/blog/index.cfm/2006/12/14/Rail.... If this doesn't show you there's a serious problem with CFC implementation, I can't imagine what might persuade you.
As for me saying that "no one is really building apps this way", no, sadly, people ARE building apps this way. I regularly get emails from people shocked to find that instantiating a few hundred objects is extremely expensive. What, exactly, do you suggest I offer them for advice? Don't worry -- they'll fix it in the next release?
Point 2: The future of web development. I have, for some time, argued that developers need to understand that a fundamental shift has occurred from the Request-Wait-Response model that we used a decade ago and that of today. Adobe has been ahead of this adoption curve and no developer I know of who has seriously looked at Flex has anything but respect for it, including me. However -- and this is obviously my own attempt at prognostication -- I think that JavaScript is very much the future of web development. No company perhaps has been more cognizant of this than has Google. For many developers, Google Maps was a revelation of what could be done in the browser. With the early look at Wave, Google continues to show just what can be done with the browser and JavaScript. HTML 5 promises to offer capabilities than will allow us to build applications that are barely distinguishable from desktop ones. I think that Flex will have a terrific future as a niche environment (I say that with NO disparagement), but that mainstream websites and web applications will continue to rely on HTML and JavaScript.
We hear one argument that no one is forcing anyone to adopt OO. Very true -- and very misleading. New developers seeking to learn investigating ColdFusion will see virtually nothing but posts on how OO in ColdFusion will solve their problems. When their experience is otherwise, they're often told, "Ah, you're not doing REAL OO", by which is meant that they just need to follow MORE of the advice that got them into this bind to begin with.
I receive quite a few emails from people who are terribly frustrated, as Marc was. They have tried to do everything just right -- and their applications are more complex and less performant. I have no illusions that my post (or Marc's) will persuade people from the OO religion that promises technical salvation to its accolytes; rather, I'm writing to those who are confused and may blame themselves for not doing OO right. To them, I continue to say: you have been misled.
As you can see my primary issue is with the generic "they" that are saying generic things like "Ah, you're not doing REAL OO" to people all over the place. Its a very broad brush, as you say, and seems to have given voice to a sense of anger and entitlement that isn't deserved. The message coming from Marc's blog and the comments there and here is that "we want free advice from unpaid people - but we only want the advice we want to read." I get the general frustration but what I don't get is this sense, which you seem to be giving your tacit approval to, that people who shared with the community as they learned should somehow be torn down because some people disagree with or don't like their advice. Its an entitled mixed with anger that is enough to make someone (like myself) want to step away from the community for a while (especially when people like you seem to think that it goes beyond just being understandable to being justifiable" and "right).
Sadly, I think Marc's tone has allowed this whole discussion to sink into the pits. Perhaps a less angry and attacking tone could have led to a more constructive conversation.
As Brian pointed out, he was the one who showed me the 1200 line XML file. Mark, you suggest that it could be broken into smaller files. Brian asserts that it's really not a problem since he was able to generate the XML file. I maintain that the problem is that the reason for the problem is the idea that everything must be an object. Once that noxious idea is accepted (and, again, this is specific to CF and its poor performance with objects), an enormous problem is introduced that then must be mediated.
But why do we encounter the problem in the first place? I hold that it is because we have slavishly followed other languages -- Java, in particular -- that do NOT have the performance issues with objects that ColdFusion has. Most other OO language developers have at their disposal OO databases that remove the mismatch between objects and the relational model. Not so ColdFusion. That leads us to things like Transfer and Reactor -- and 1200-line XML files.
As Brian can attest to, I have ranted for a long time about the wrongness of letting the database drive the object model. Mark Twain once said, "Everybody complains about the weather, but no one does anything about it." So I decided to.
Some time ago, I wrote an object persistence library that, unlike Transfer and Reactor, would NOT start with the database, but instead with objects, generating the needed tables and SQL to persist objects. It took a good amount of time and we've used it on several projects. The problem is performance.
I had planned to show this at CFObjective last year. In preparation for that, I created a "HenryVIII" object that included Henry's wives, mistresses, their parents, offspring, etc. I chose Henry because of the complex relationships, circular references, etc that a robust object persistence layer must be able to deal with. I was very pleased with its simplicity. To save Henry (and the 60-odd accompanying objects) to the database, I only had to do this:
pl.persist(henryviii)
To get the complex object FROM the database simply required this:
pl.load('henryviii')
Nice.
Well, nice if you have 45 seconds or so to wait.
About a year ago, I did some extensive experiments with creating an OO UI layer. Creating a Page object that held smaller objects that knew how to display and edit themselves was greatly appealing. I thought building a CMS around this would be particularly nice. Elements need not be simple HTML elements, but could be more complex ones, making assembling and editing web pages far easier.
I really liked the idea and I was happy with my plan -- until I ran into the problem of performance. Unhappily, I shelved the idea.
CF's poor performance wrt objects means that OO development in CF is particularly UNsuited for complex applications -- the very kind that OO should shine at.
My -- and Marc's -- rant against OO-mania in the CF world is that it promises what it can't deliver. This is NOT a generic rant against OO. That would be supremely silly. I still remember the thrill of seeing objects done in Smalltalk at PARC and feeling that I had a really viable way of managing complexity in software. I find that OO resonates deeply with me and, I suspect, with the CFers who really want CF to be able to deliver on OO. But there comes a time when someone must say, "The splendily-clad emperor simply has no clothes on."
Far, far, far be it for me to criticize the bloggers who offer help to so many. I'm very serious about this. I think people like Sean, Ray, Ben, Brian, Joe, yourself -- and many others -- have done a tremendous service. I don't think that what Marc meant, but I'll let him speak for himself. As for me, that was absolutely NEVER my intent. Rather, it was to say that an unfortunate mentality has crept into the CF community. That is what I am speaking against. I hope you can see the difference.
I'm with you. I love OO. It appeals to both the philosophical and the practical aspects of my nature. Without wanting to be egotistical, I think I can say I have done as much as anyone in the CF world to evangelize objects and to show the power of OO development.
I think CF developers have been quick to adopt new practices and embrace good ideas, but our loyalty to ColdFusion has not been repaid by Adobe. Object creation is absurdly expensive. What brilliant mind decided to decompose a CFC into separate Java classes for each method? What committee decided that interfaces were a good idea in a dynamic language? And now, they're going to layer Hibernate onto this? I shudder to imagine just how bad this is going to be. If I'm wrong, I will be wrong happily -- and will publicly own my foolishness. But the history of ColdFusion doesn't make me sanguine over the prospects of introducing an ORM.
Here is the bigger question? Where are our solutions? We can chat all day about our methodologies and technology but without product those are like the classic my dad is bigger than your dad arguments! :)
I wish that object creation was not so expensive, hopefully that is something that will get better (or maybe even redesinged) in future versions of CF.
This is a bit of a tangent from the rest of the discussion going on here, but the real point is that regardless of whether you want to deal with objects or result sets, you have to have database queries. If you have 50 tables, and you need create, read, update, delete, and list queries for all 50 tables, that's a LOT of cfquery tags to write. And if some of those tables are related, and you need JOIN queries in addition to single-table ones, the number of queries probably doubles. We're talking about thousands, and maybe tens of thousands, of lines of SQL that has to be created one way or the other.
I'm not ashamed to say I'm pretty good at SQL. I actually enjoy solving big, nasty data mining and reporting problems with it. But the mundane select and insert statements is just the most boring and time consuming thing I can imagine, so I try to avoid it. I'm pretty sure that even in your ORM implementation, if you took all the cfproperty tags to define properties and relationships out of all 50 domain objects and put them in one file, it would be the same amount of configuration. The only difference is which file(s) the config info is kept in.
Anyway, to return to the main discussion thread, there seems to be two issues being exposed here. One is whether OO itself is useful for the kinds of applications that most CF developers build. The other is whether OO at all is practical due to the implementation of CFCs in the CF engine itself.
They're really two separate issues. Whether CF is "fast enough" to do OO depends on your application and how many objects you're dealing with. Whether OO is applicable to your application depends on the background of the developer, their understanding of OO principles, and the complexity of the application being developed.
I've talked at length with the CF engineering team about my problems with CFC creation speed. While I agree with Hal that "wait for the next version" isn't a very good answer, I can say that if they can reach the goals they've set for CF9 in terms of CFC speed, that side of things will be much less of an issue.
But even if one were to say "I personally don't think CF is fast enough to do what I need to do from an OO development perspective", I'm not sure that should absolve them of the reality that learning OO is only going to be a benefit to their career in the long term. I think there are still a lot of good ideas that can be applied even if one doesn't go "full bore" and make *everything* an object or array of objects.
I still think the problem really comes down to the fact that there is no switch one can flip to "know OO". If someone sees a simple example, they say "it's too simple". If they see a complex example, they say "it's too complicated". People try to adopt what they see, without really understanding the reasoning and tradeoffs that were considered before reaching that design. The underlying design forces differ between problems. But unfortunately the ability to assess those tradeoffs is something that only comes with experience. So it's a bit of a Catch-22.
But is that really much different than learning anything? If you try to learn to write music, it takes a lot of trial and error and patience. You can read books or take classes, but in the end, only practice actually gets you anywhere.
In fact, it's somewhat humorous in that it looks like the frameworks vs. no frameworks debates of yore, with the same cast of characters lining up for the former and Marc Funaro - and perhaps now Hal - taking on Simon Horwith's old role!
@Brian R. - I've read every post that's been a result of Marc Funaro's original entry - whether comments on his blog or all the other posts that were in response to it - and the only "easily offended" group I see are those "OO gurus" (OOGs) not the "unwashed masses" (UMs)? In fact you seem to be the one "looking for offense" here? Others who have used phrases similar to "the debate is over and OO has won" and other such absolutes seem much angrier (for lack of a better word) than those saying things like "thanks for saying what I've been feeling all along" to Marc.
I have seen plenty of comments defending the OOG's and frankly most of them are spot on: most OOGs have indeed said that OO is hard, said that there is no one true way, have said to ease into it on small projects first, read this book and that book, etc. (sean Corfield comes to mind here...) However, Marc's initial post aside I really have not seen many UMs stating the opposite? My opinion is that to come to that conclusion, people are reading between the lines and coming up with an incorrect conclusion.
Nor have I really seen anyone knocking bloggers, OOGs or otherwise, for presenting their opinions and providing their "free" advice to the community. I applaud all of them for their openness, helpful attitude and the body of work that they have selflessly shared with the community. I have learned a great deal from all of them and hope to continue to do so.
I will respond to just one small point here, and do so with what is just _my_ opinion, and that is re: the "beyond reparable" issue. Like Brian R. - I'm not really sure what that means? However, I have seen other commenters allude to something similar in this whole debate. While for the most part I find it a silly sentiment, there is an area where it can definitely ring true: the future direction of CFML.
For those of us who are fortunate enough to participate in certain pre-release programs, we get an inside look at the making of this sausage... and the debates and discussions there are wonderful, insightful and even fascinating at times. It's too bad everyone is unable to digest them. However, if the OOGs are a small minority in the "real world" of CF, they certainly are - if not in the majority - perhaps "overrepresented" in these programs. Certainly they are the most vocal. If you look at the OpenBD team and recent additions to the Railo teams, I think you'll find the same make-up.
To me, this says that people of a particular mindset have much more influence over the future of these products than others... assuming that is in the least bit correct, then does that mean that Adobe, for instance, is spending more time on features for the OOGs and less time on features that could benefit the greater majority of CF coders? Is that how CFinterface and the Hibernate integration were born? Is this even a bad thing?
Anyway, in the end, perhaps the "fear" of this vocal minority having a large influence over the future of this product/language is what the underlying angst, that's may appear to be bubbling up in some of the UM's posts and comments over the past week...
Apologies for the long comment.
But to correct your knowledge of how the decisions are made about what features are included in a new version of CF. There is a Sync-Dev process they go through and meet with tons of company's around the country with developers "on the ground" (and not just "gurus"). This is where the big decisions about major features tend to be made.
Why? idunno, for sure. There's competition in the market, perhaps more than in the past (we used cf to replace perl and notes apps back then). CF seems to be sliding into the cracks within Adobe's product line, which is a bit more unwieldy than allaire's or macromedia's. And, bringing new people in doesn't appear to be the priority it once was.
So, and again this is perception, fewer new people + layers of additional complication and opportunities for confusion = a much easier path to "why bother," RoR, or any other competing technology.
CF's always seemed to be a niche technology. By creating even the appearance of additional barrier to adoption, you eventually run out of new people, and eventually it's too late, beyond repair.
As for my knowledge of the process, I do know how it works as I have been fortunate enough to have been (be) a part of it. My point was that the OOGs are more highly represented in (at least partof) the process than they are in the real world and, more so, that this perception "could be" where some of the angst from the UMs may be coming from in these responses. I apologize for the terms OOG and UM - -it was for brevity's sake.
Well said.
Yes, Andy, the irony of this has not been lost on me...
In all the words that have been used during the various discussions, I've yet to see (or, again, maybe I missed it or was supposed to assume it), a single cogent well-defined example articulating "the OO problem".
I'm not saying this snarkily... I'm very serious. I'd like to see examples of the problems people are having with "the OO approach". *Why are things difficult/complex?* has become a fascination of mine as of late, and so I'm interested in less finger-pointy, generic hyperbole and a fuller, more specific treatment of the issue.
If the issue is, at its root, about "beans and DAOs and gateways, oh my", then that's one thing. I don't mean to minimize it. If, however, it's about "more than that", then I fear this discussion will continue its descent into navel-gazing unless we get more specific.
I'm not sure what you mean by "the OO problem". But certainly the idea that development is all abut beans and DAOs and gateways is, for me, absolutely incorrect and a lot of developers are going down that path.
What I mean in general is "What is at the root of the problem that Marc and many others are having with applying OO methodology to CF?" I don't mean "you're dumb, what's your problem... not at all. I simply am curious if the root of the problem isn't "OO" but is in fact "beans and daos".
Like, imagine some ideal world where you could take the database out of the picture, and you didn't have the object instantiation penalty, and you were left with (forgive me, Lord) "business objects" and doing "business logic". i.e. all the crap you've always done in cfmodule and the act_XXX files you'd cfinclude. If you were left with just that stuff, would people still have a hard time with an object-oriented approach to those exact same things?
Perhaps this is a false distinction. What I really want to know is this: did this strike a nerve with so many people because something inside them said "this bean stuff... it's bullshit, and I know it's not right but I don't know what else to do and still be OO-y?" Or is it about more than just beans and persistence?
Exactly. It is just not made for OO, and it is just not made for large and complex applications.
Show me an Aerospace company that uses ColdFusion for its core products and I'll never catch a plane again.
What about the development tools? After working with .Net, and being spoiled by the IDE and all the third party tools available, I was very bummed to have to go back to ColdFusion. Can I have some fricking tools here, please?
There are some comments you have made here, that I have to disagree with wholeheartedly, as it seems like they are aimed fairly squarely at either me, or software I've written.
Re:
--
That, in and of itself, is not a particular problem. Different languages have different strengths (and weaknesses). What I perceive to be a very real problem is that OO in CF land has become a religion -- and its adherents ignore the problems with OO in CF. Honestly, when was the last time you read a post talking about the terrible performance of objects in CF and (possibly) proposing a solution?
--
From a personal perspective, the very fact that Transfer was architected the way it was, was to try and avoid the object creation performance hit, which is why the cache is so heavily utilised, and you can't retrieve an array of objects out of Transfer directly, you can only retrieve queries.
On top of that, if you look through the google group, performance is a topic that has come up time and time again, and I'd like to think that I've offered pragmatic advice on the pro's and cons of approaches from both an OO and also a performance perspective.
Extending from there, just coming from cf.Objective(), there were several presentations this year, AND in the past that have specifically addressed this problem.
Looking at various blog posts and mailing lists, I can find references to discussions of patterns such as IBO's, using Queries rather than arrays of Objects, and the inherent expensive nature of CFC creation (which no-one has ever debated) and how to get around it. So I think the information IS out there, if you want to go look for it.
To enhance my point even further, you can see why a few more vocal community members have blogged and spoken about how to incorporate Groovy / Java into your Domain Model, which does allow you to take advantage of more OO constructs, without taking the performance hit. They admit and acknowledge the CFC issue, and are taking strides to help people work around it!
Re:
--
Some time ago, I wrote an object persistence library that, unlike Transfer and Reactor, would NOT start with the database, but instead with objects, generating the needed tables and SQL to persist objects. It took a good amount of time and we've used it on several projects. The problem is performance.
--
I can only really talk to Transfer here, but your statement that Transfer starts from the database is plain wrong. It only starts from the database if that's the way the developer chooses to use it.
I've challenged your statement before, asking you to explain why you felt it started from the database, and those challenges have been left unresponded to, so I can only feel you really haven't spent time to actually understand what Transfer is doing.
I can happily attest to the fact that Transfer could make life easier to start from an Object perspective, in that it could create the DDL for you, and we are working on that, and there are some limiting factors with what is possible with Transfer (i.e. no inheritance support, yet), but there is nothing stopping you from taking the following approach:
* Designing your OO model in UML
* Representing that OO Model in the configuration XML for Transfer
* Building your database to allow for the OO model written in the XML configuration to allow the Objects to be persisted.
Now, in Brian's case (sorry to single you our Brian), where he generated the XML file from the DB, yes, that was Database driven, but THAT is a developer choice, not a problem with the persistence framework. Most people seem to agree Hibernate lets you start from an OO perspective, but I can also point Hibernate Tools at a Database and make it generate Objects for me - does that mean that Hibernate also starts from the Database? I don't think so, not unless the developer decides to do it that way, and I assume the developer would be making a pragmatic decision about solving a particular problem.
I have to also point out the irony of you writing an entire blog post advocating pragmatism when applying OO to ColdFusion, yet when the same pragmatism is applied to persistence frameworks, you seem to be taking a stance of OO purity, in that it CAN'T ever start from the DB. I can only honestly say that sometimes, starting from the DB is the only choice you have, especially when using a Legacy database, and you have to work your best around it.
At the end of the day, I think a lot of this 'OO debate' (which I think is a ridiculous term in and of itself, considering OO has been the predominant programming strategy for more years than I've been alive), is in and of itself mostly born out of fear.
I spend a fair amount of time helping various software shops increase their development skills, and give them strategies to enable them to build software better, i.e. on time, with less bugs, and faster than they did previously, so I've seen the same frustration and fear play out time and time again, as people struggle to eat the entire Software Development practices handbook in one bite, rather than piece by piece, or just plain ol' freak out, because they are worried that they will 'fail' somehow in what they are doing, and therefore never take a new step. From that perspective, it is so easy to fall back on 'OO is bad', or 'OO will never work in the real world', because there is an inherent emotional block to learning something new, so yes, for that person, it won't work, because their fear won't let them.
What we should really be talking about are ways in which to mitigate that fear - to show people that learning something new it's scary, it's EXCITING. That failure (generally speaking), isn't some dark spectre looming over our heads, it's one of the best ways to learn.
There is a term in martial arts which is 'Invest in Loss', which I think applies perfectly here. It means that you should often train from a position of weakness, train from a position where someone has already beaten you, because failure is one of the best learning tools out there, and at any given point and time, there is always going to be someone faster, smarter and meaner than you are - so you should know what it like to be beaten, so you can survive and come back from it.
Those people who you've referred to as the 'kewl kids' (which is also a term I despise, as it advocates some form of elitism, which I've always tried to avoid, and I hope anyone who has met me doesn't have that impression of me), already seem to know this, either learned or instinctively, and are simply excited to learn new things every day, and try out new practices, regardless of whether they work or not, and then regularly blog about them. Often to the advantage of those who read their works.
Now I'm not advocating people should go tank that 3Million dollar enterprise project, but I think a lot of developers, particularly in the CF world, should invest in a little loss. They should step outside their comfort zone, be it procedural to OO, CF to Flex, CF to Java, take your pick. Yes, it will be scary, and yes, you will get things 'wrong', but it should be really exciting, as new opportunities and new ideas come to you as you work through problems, and solutions. I feel that if more developers did that, then we'd have less of these sorts of 'debates', and more solutions to problems.
I'm sorry if I've offended anyone with this post, as I generally try and take a professional tone with all my dealings, but this is something I feel quite passionately about, and I felt it needed a decent response.
You seem to be throwing grenades towards Adobe and making some general assumptions on what is driving the direction of ColdFusion. I'm actually quite surprised of how matter of fact you've been considering your lack involvement in the direction of ColdFusion. We'd love to have your input, but we can't force you to join the discussion or log into the prerelease.
Linking to a speed comparison for ColdFusion 6 is a bit irresponsible. While I don't believe CFC performance is where it should be (yet), it's definitely much faster in ColdFusion 8. In the lab ColdFusion 9 is testing much faster than the other clone engines.
As far as ORM goes, we can actually get CFCs in/out of Hibernate faster than POJOs. I don't know where you get the '45 seconds' from, but that is likely the first load of Hibernate firing up. As far as complexity goes, ORM is as much for the entry level developer who doesn't want to hassle with SQL than it is for the advanced OO developer who doesn't want to have to code in relational terms.
In terms of the new ColdFusion IDE, again you look to be spreading concern without participating in its direction. How concerned could you be considering your lack of activity in the prerelease forums and private mailing lists? Obviously not concerned enough to login more than 2x. I really don't mean to call you out on this, but as an ColdFusion ACE I think most people assume you are 'in the know' and more closely involved.
If you think that the advanced developers are driving too much of the direction for ColdFusion, then step up and get involved. ColdFusion 9 definitely has some advanced features, but that doesn't mean that we've forgotten the junior developer.
-Adam Lehman
ColdFusion Product Manager
They were blown away by how simple it looked to use and how much work it could save them in terms of simple CRUD work. As far as they were concerned, the requirement to use CFCs to leverage Hibernate was just fine because the only thing they saw was an annotated struct. Jason didn't present this as an OO solution and no one was scared off by it.
I'm sure that Adobe's Sync-Dev process has verified this approach with a broad range of developers. Sure, some CFers are going to latch onto Hibernate integration to make their apps "even more OO compliant" but for the vast majority of CFers, Hibernate integration just means simple CRUD functions.
Given all the OO promotion you've done and the training courses you've offered over the years, it seems a little strange to hear you apparently backtracking and now calling OO in CF a religion - you've been at the forefront of pushing OO all this time! Your training page shows two OO courses and an OO-Ready quiz with the byline "The remedy for confusion and frustration: deep knowledge." which just emphasizes how hard this stuff is and how long it can take to learn (hey, maybe they could take one of your courses?).
You constantly talk about the misinformation being spread in the CF community about OO: please post some URLs where we can see this misinformation - and your analysis - so that we can all take the time to understand where these bad messages are coming from and what is fundamentally wrong with them. That would be a bigger benefit to the community than what you seem to be doing in this blog post.
"Today, OO in the ColdFusion world has become something of a religion. As Marc discovered, it's impossible to say a bad word about OO without one's sanity, intelligence, and motives being questioned."
It seems to me that the last few comments back this point up, don't they?
"OO implementation was done so ill-advisedly in ColdFusion, with each CFC method represented as a separate class in Java. The hit to performance this occasioned has been nearly fatal."
This is nothing new, is it? The OOP proponents are the ones heralding this shortcoming loudest, aren't they?
"so much energy has gone into trying to get ColdFusion to behave as a proper OO language."
Well... this is true, right? Adam's comment echos this. Some will say keep up the good work, others will say spend more time on speed, others will say spend more time on video encoding or something...
"'kewl kids', ever on the lookout for the newest thing, long ago left ColdFusion... [for] Ruby"
Clearly - he's talking about those who already left the community, not those of you responding here. Don't project. He says as much in in the next sentence and in his follow-up comments.
"Will it be the long-awaited IDE that will deliver a world-class ColdFusion editor? Like you, I certainly hope so, but I do so with trepidation."
What's wrong with this statement? I hope it will too!
"frameworks in the CF world proliferated, I find myself feeling that they have grown too big and too intrusive"
This echos the sentiments of many, the frameworks v. no-frameworks debates I alluded to earlier are rife with arguments backing up this opinion.
"there is a real cost to the mindless pursuit of OO in the ColdFusion world for its own sake, heedless of any measurable benefits."
Isn't this the statement the really sums up the whole pseudo debate... the 'money statement' if you will? Isn't this really the statement that both/all sides of this argument are actually agreeing on???
"I shudder to imagine just how bad this is going to be. If I'm wrong, I will be wrong happily -- and will publicly own my foolishness."
Adam - I and many others do seriously hope you make Hal eat his words here! Apparently, so does Hal.
The only statement I could find that is pretty much off the mark is this one:
"Honestly, when was the last time you read a post talking about the terrible performance of objects in CF and (possibly) proposing a solution?"
Actually, I think we see these all the time... along with healthy debates on proposed solutions... Peter Bell's IBO series is the obvious one that comes to mind.
In the end, I really think people ought to chill out...
It is odd to people arguing against me for things that I haven't said, but I think that's what happens when emotions get stirred up. I do understand and accept that. The most unfortunate misunderstanding was regarding my comment about the "kewl kids". You are completely correct: I was never referring to any CFers, but to those developers who long ago left CF for the latest craze.
I have great empathy with the many ColdFusion developers who did not graduate with a CS or Software Engineering degree and who found themselves becoming developers. As I've related many times, I started in the woodworking world! It's never fun to have people criticize you, but I hope, in the end, that all this may lead to some real good for the community.
Again, thanks.
I agree, it seems my comment about 'kewl kids' was misplaced, what I should have referred to was the comment:
'The CF world has split into a relatively small, but highly vocal, cadre of people who "get" OO -- and the vast, unwashed masses who must, like Marc, spend their time working on real projects for real clients.'
Which still instils the same emotional response as the 'kewl kids' statement I had misread - that those of the 'vocal minority', don't really work on real projects, but are still giving out advice to those who are 'working on real projects', and in your opinion, it is wrong. Quite frankly, I find this fairly insulting, especially as you refuse to give specific examples. I can think of which people you may well be referring to that are the 'vocal minority', and the people I know all have real world experience, and give away much of their time *for free* to help pass on any knowledge they have gleaned from the years of development work they have participated in, in what I can assure you are 'real projects'. To what end you are attempting to promote a separation within the CF community, I'm not entirely sure, but I would suggest that in the future, you would attempt to promote unity, and attempt to bridge the divide, real or imaginary, rather than attempt to rift it further.
Re:
--
I was pretty sure some developers would be unhappy with me for posting it.
--
I don't think that's the point many people have made on this post. They aren't unhappy with you for posting it, they're unhappy (myself included), because they have raised valid counter arguments against the statements you have made, many of which are contradictory in nature, and you have yet to respond to a single one of them. Instead, you seem to have chosen to take a passive aggressive stance, and focus on a minor misrepresentation of one of your statements, which does not encourage a positive resolution.
Since you have also claimed '...but I hope, in the end, that all this may lead to some real good for the community', wouldn't it make sense for you to participate in some, open and honest discource with those people who have provided counter points? That way everyone can learn from the discussion and take away something positive?
Clearly more than just I were insulted and disturbed by your post here - in part because its hugely hypocritical from someone who makes a living off of selling OO training to the ColdFusion world. Unless of course we're left to believe you are the only one who isn't a fanatic.
It is a deeper issue than accusing one side of being religiously finatical when they can justify their take. The bigger issue is methodologies are like design patterns. One size does not fit all. In one case the pattern is a solution and in another case the pattern is an anti-pattern. When you need a vehicle sometimes you may need a semi and another you might need a dump truck. All trucks are not equal.
With that said I think the more we learn about OO in 'general' the better we will be at writing applications. Yet there is an undue arrogance and hostility towards those who do OO programming. There is an apparent air of snobbish superiority that stirs this conversation. Yes, there is occasionally an inferiority complex also but less often than those of us who do design patterns might choose to excuse.
Hal said last year in a session at CF United that your application doesn't run faster because you use OO code. (Of course clean OO code replacing poorly written proceedural code will normally run faster.) Sean has said that there are trade-offs. Typically there are great benefits to doing more OO than none.
At the end of the day you and I have to look beyond the technical merit of the tradeoffs to the business realities of software development also. IMO many of the gurus have not shown the ability to see beyond the big ticket jobs and sales scenarios in evaluation. :) (This is my opinion that money for the developer is driving this typically without those making the arguments realizing personal gain is part of the consideration.)
Guys, this post wasn't meant for you. It was meant for the many ColdFusion developers who are confused and concerned by a goal line that ever seems to recede as more and more frameworks, patterns, libraries are layered on. That you take such offense is something I can't help you with. If, as you believe, I'm wrong, that will become obvious. If you're right that things are just ducky, that too will become clear. In the meantime, ad hominem attacks (I'm passive-aggressive, I'm a hypocrite, etc.) don't really advance your cause. Can we, perhaps, cool down the rhetoric?
My contention should be clear from my post and my lengthy responses: I think something is seriously amiss in the CF world. Either that's true or it isn't. I'm quite convinced that a flame war is useless at determining the truth value of a statement.
Clearly, what Marc and I said has touched a nerve. Now, if I were to say, "ColdFusion is terrible because it doesn't support variables", you might respond with a simple, "Uh, no, that's not right." The statement would be so obviously false that it wouldn't be worth getting exercised about.
Just consider why someone very much involved with and an advocate for OO would write the post I did. It was certain to win me favor neither from Adobe nor from some developers whom I knew would take offense. It was, in short, not a good "career move". Now, I may have lost my mind (one hopes temporarily), or it may be that I did this because I felt the pain from receiving emails from developers who are deeply troubled, sometimes really in despair, over the problems with trying to do OO as prescribed in ColdFusion. They're being told one thing -- and experiencing something else. These were the people the post was meant for. If you wish to see dark, sinister motives in my post, I'm afraid no amount of clarification or going back-and-forth will assuage that feeling.
Without specifics, all this stuff has a Boo Radley feel about it.
Fusebox
Mach II
Model Glue
Transfer
Etc...
But the presos that I seen so far have the author spending have the time talking about himself and only showing 2 lines of code. I can care less who you are, show me the damn code. Stop yapping about where you worked and show me how to use the software.
I know i'm not the only one here that feels this way either!
I will take that to heart and cut my personal itroduction to 1/10th of my presos in the future... you might be right that 90% of my preso is to much! :)
I would classify myself as a fairly strong cf developer who is constantly learning and improving. Am I an expert at all things OO, no way. Can I use it if I need to, heck yes. Will I embrace Hibernate even though I started my career with an almost singular focus on RDBMS platforms and would consider myself better than average at most things database related and a nutjobber control freak - you bet I will give Hibernate a shot.
I consider many of you guys posting on this topic to be experts that I look up to but I'm kind of feeling like I need to jump up and shout "Can't we all just get along?".
Then it occurred to me that much of the wisdom that I have I learned from Star Wars!
You know the scene in Episode 3 before the big battle when Anakin has totally lost his mind and Obi Wan points out that he's dealing in total absolutes? That's what some of the contributors to this discussion sound like. Let me be the moderately skilled voice of reason here and say that we need to do exactly what we're already doing - sound stupid? Here's what I mean...
I was drawn to CF because I had worked in languages like Visual Basic and Object Pascal (and I was also starting learn a small bit of Java at the time too) and I thought that CF seemed like an awesome tool that I could pick up quickly and get things done fast, fast, fast!
That was a bit over 5 years ago and you know what - I still love it. Along the way I've learned a lot about AJAX and somewhere around the time version 7 came out I started doing everything in CFCs but really I would say that I'm pretty procedural and that a lot of these CFCs are just function libraries (there's not true framework in my apps - but they are highly organized and documented). No matter, CF allows me to be a one man wrecking crew and code circles around 2 or 3 guys who are using snobbier tools. It's all about making people happy and doing the best job that you can.
If the OO experts want to create a flux capacitor that does everything all the way up to cf_goCleanOutTheGarage then that's awesome - go for it. If there are guys that started with CF in version 4 and wrote their organization's killer app and they want to just coast and maintain it and maybe add a couple new features or reports to it here or there then that's awesome too.
My point is that CF is great because you can go super simple, ultra OO or somewhere in the middle like me and you're going to be productive no matter what. Trust me that there are reasonable people steering the respective Adobe, BD and Railo ships that want to attract developers of all shapes and sizes (and ability/experience levels). There's something here for everyone and we should stop dealing in absolutes and one size fits all approaches. You can't argue with Obi Wan!
Guys, this post wasn't meant for you."
Unless you call out the "misinformation", you're justing spreading Fear, Uncertainty and Doubt. If there's bad information out there, please call it out and give us your analysis as to why it's wrong.
"It was meant for the many ColdFusion developers who are confused and concerned by a goal line that ever seems to recede as more and more frameworks, patterns, libraries are layered on."
I don't think it helps them. All you're doing is setting up a mindset that allows them to demonize OO because you keep saying there's a lot of bad information out there and they should ignore it - without telling them what is good and what is bad.
"That you take such offense is something I can't help you with."
I don't take offense at all. I'm just disappointed that you're being so vague.
Remember that you "wrote the book" on OO in CF, literally with your "Discovering CFCs" book but it is woefully out of date and contains a lot of - what is now - bad information about how to use CFCs, based on a faulty implementation (CFMX 6.0). Where is the updated version with better information?
All I'm asking is that you help us, all of us, by shining your light on the good and the bad out there with specifics so that we know what to read, what to avoid and - if we're the authors of "bad" OO information - what we need to correct.
BTW, you criticize the "religion" aspect of OO in CF but even you said "preaching OO was lonely work" which is about as religious a parallel as I can imagine.
I think the one thing we can all agree on hopefully is that there is a knowledge gap in the CFML community. Coupled with that is the problem that it seems that most CFML developers try to learn every new thing *at the same time*. Maybe even a worse thing is that some CFML developers think they *have* to learn it all at once. Sadly, there are the few that actually do attempt to learn it all at once. I think this addresses Hal's point about receiving emails from "depressed" developers.
I pose this example. Session facades have been become a "hot" topic on the Mach-II list. I think three separate questions have been asked in the past three week alone on the list (plus, one email to me personally). Now, I don't want to get into the debate *about* session facades (so spare the debate - this is for illustration only). Each time, the person asks for a concrete and "right way" to do a session facade(s) and they get a little upset when you say it depends and show something more generic. This applies to anything OO related as nobody wants to do it "wrong" way so I think this is where younger OOP people wear the "religion" cloak for a while. Anyways, I know I tried at least three different ways of doing a session facade in several applications (from concrete methods to generic getters/setters to multiple facades). In the end it was all practice and I was able to find a method that I was comfortable with and flexible in my application at the time.
So how did I feel when I'm learning something new? Sometimes I feel great and all was right in the world and sometimes I feel like I was a stupid moron who shouldn't be allowed withing 10 feet of a keyboard. Again, it is practice that makes you smarter. And maybe it's not the practice itself that does it, I think it's about the process and getting to the point where you are able to self-evaluate and realize you need to take a different path to find a solution to a problem.
I think the solution to this debate is tell people to get back to basics. I'm not talking about OOP fundamentals or general development methodologies, but I'm talking about reminding people that learning requires effort and time. In this type of job, learning never stops. You can't be an expert in everything (gosh, I did my first big task with cfdocument just a few months ago - yes, literally).
Lastly, getting from point A to point B is not a straight line. As you are learning something, you'll have a *lot* of deviations to learn other things along the way. For example (a couple years ago), I was working with serving files via cfcontent and needed to do some stuff with headers. I ended up fixing some "problems" after getting into YSlow land and learning more about how browsers work with this metadata from web server responses, yadda, yadda. What about my cfcontent/header stuff? Oh, that got done, but I never expected to get so into YSlow at the time. So there is my example of taking strange paths to get to you end point.
I think the only thing that bloggers/people that are pushing OOP on CFML developers are guilty of is forgetting to tell people that learning is hard, that is won't happen over night and that is there is no one true way. Who's to say my approach will work better for you than another person's approach (there is the reason why we have more than one MVC framework in CFML land). And if you think sometime is wrong in the CFML world by the proliferation of frameworks -- just go live in the Java world for a while.
There are plenty of code-centric presos on UGTV about frameworks and most authors have only one slide about themselves. Care to sign your name and actually be specific instead of hiding behind anonymity and vague criticisms?
Finally read all that, whew! (I laughed, I cried, yadda, yadda ;-)
I'm a non-OO CF architect (though I can fumble may way through fairly simple OO applications), which means I tend to work at companies with fairly large/complex legacy CF 4/5 apps that have grown to CF 8 Enterprise apps, but usually without time to re-architect into OO or a Framework.
I'm confident in saying that in my 5 CF jobs in 8.5 years that *not being OO* was never the problem with these under-performing apps. At one job where a home-grown OO architecture was used, being too OO was definitely the problem, and I had to write a caching layer on top of it just to keep the thing from crashing CF under moderate load... though, it did get better after the upgrade to CF8.
I suspect there are many other lead developers/architects out there in a similar place as myself, but we aren't vocal enough about how we architect scalable CF Enterprise systems in a procedural way - with reusable code in CustomTags and tons of CFC singletons cached in Application or Server scope, etc.
In a non-OO CF app that needs to scale to dozens (or more) requests per second and multiple CF instances, the performance problems I see aren't related to too much Object instatiation, but to slow queries, too little memory for the JVM, trying to do too much in a huge cfloop, external SOAP calls, old CFX tags, etc.
I should really blog this, but to get things rolling, here's some top issues (in no particular order) to look for when your procedural CF application is not performing well or scaling as you need it to:
- poorly written queries (too many sub-queries, outer joins, items in the IN clause, or records returned, etc.)
- improper or missing database indexes
- using the right amount of memory for the JVM, based on how many sessions will get created, how many queries will need to be cached, how much load each CF instance will get, how heavy Scheduled Tasks and Gateways are, CFX calls, etc)
- how many/often large files will be uploaded
- lots of image manipulation
- how Verity is setup and used
- if your JVM is running out of memory at times, and you already have it set to 1.4G or so, you may want to upgrade to 64-bit OS and CF8 64-bit
- it's getting late, and my brain it losing steam, but I know I'm forgetting some things, so please chime in
What I'm trying to point out is that there's a lot of folks out there who are having problems *bigger* than whether their system is OO or not, and there's not a lot of info out there to help them with those Enterprise-y, yet procedural, problems in CF. Let's focus more on helping people in the CF community with their big problems in the legacy apps that many of us find ourselves tethered to. It will benefit a larger portion of us than these other debates. Who's with me?! I will follow up with a blog entry soon.
peace and goodwill, CF brothers.
This just came up on Twitter (from Nathan Strutz) and he asked how many separate Java classes are created for a CFC in Railo. Answer: just one. The methods are implemented inside the generated class (FWIW, there's a UDFImpl class that is a handle to a UDF implementation, to allow for dynamic method access, but the code for the UDF is compiled directly into the class for the CFC).
I agree to both sides of this story. This is definitely something that has been bothering me as well lately.
Coldfusion Pre-OO was just a very flexible yet powerful and fast programming language to do some stuff that other languages at that time couldn't do with the same ease (talking CF5 vs asp classic and the beginning of php3/4).
Coldfusion 5 I learned through a job back in 2002. Since then I have been doing stuff for myself, several pages and later from 2004 upto 2008 websites for customers (and myself again) of my own hosting company.
All this time I haven't use much OO as such, apart from the here and there function, cfc and customtag, which I see in a way as OO, as you are reusing code.
Am currently involved into a side project with 6 people from which 3 Coldfusion programmers taught by me. In this team we make a webbased game and one of the guys told me we should make use of a framework.
This is the other side. It is pretty much required for a bigger size project and I do see the use of it. You can seperate code from views, use ORM and Transfer to generate classes for all the database handling etc. Am talking here ModelGlue-Coldspring-Transfer-Nunit (evt Mach-II).
But for small projects I still use normal Coldfusion coding without much OO stuff.
This also has to do a little with the time I have spent on learning OO and the new stuff since CF5. Basicly I am still doing CF5 stuff in CF7.02.
As I just finished my bachelor marketing, and this side project started on Mach or Model-Glue, I'll be spending more time on studying the works of OO in combination with CF and put time into the more advanced stuff of CF in general and learn ofcourse CF8...
I do agree that non-OO written CF apps often have performance issues on queries and certain ways of code use.
My current blog that I recently setup: www.stevenesser.net is still using non-OO code, the next step would be to translate the whole app to OO code and a good framework.
My general point was that for big projects it's certainly worth to think OO and model OO, especially when you have the budget for that (e.g. a biiig customer).
For best practice OO is probably the way to go. For a small simple app that will definitely not expand go non-OO.
And yeah.. if you see a project grow big see if you have time and money to spend to make it OO and put it in a framework.
As I am also into learning ASP.NET 3.5 I just have to put my time into OO. (note: I do not like asp.net, but I just see it as only possibility in current economical crisis to get some kind of job).
What astonishes me is when I read in an article of an old issue of CFDJ (2006) that the chief in editor has invented a new METHODOLOGY, hmm, framework, ok, but a METHODOLOGY, comprising all the tools (CASE) and paradigms etc...I'm assuming this statement was also due to a lack of a proper education in computer sciences.
cheers
oscar
http://corfield.org/entry/Simonology
I read your article on "An Architect's View" about the controversial topic
we're referring to. Very interesting and I highly approve.
Hopefully, I'm able to point out what the real problem is: The term "software crisis" is well documented and we all (should) know and should have been taught at university the reasons
of this phenomena.
Sometimes I don't see why so many "programmers" don't realize that programming is an engineering discipline plus a social act plus a psychological act. Besides the fact that no engineer let's say in air crafting would
waste time in reinventing the wheel (for instance turbines or whatever), they try to evolve their products and effectiveness. There are standards (Methods) and best practices (Patterns) to reduce complexity and to
handle what someone called "aging of software" (SLC). But this approach requires two things: to say goodbye to "I solve the problem in my own way, no matter if the problem has already been solved by others" and to
embrace what software engineering represents. An engineering discipline and a highly complex work, so I can't stand when someone reads two or three books and than says: "hey guys, I have a new "ology" that solves all
your problems...". Sorry, I can take this seriously, worse enough that this is issued in "developer's journal"...
cheers
oscar
Guess what folks, all sorts of people are drawn to ColdFusion because it is simple to learn and ultimately a highly productive environment to work in.
Everyone out there just needs to let this thread die. I seriously don't care if you have a computer science degree or not. It basically comes down to - Can you write an application that performs well, is secure and meets your user's specifications? Can it be reasonably maintained and is it well documented?
Guess what, I've been working as a software developer for going on 13 years and I don't have a computer science degree (gasp, oooooooh, ahhhh, owwww from the crowd of onlookers). What I do have is a business degree and a solid understanding of how to take my client's requests and turn them into tangible solutions - period.
I've written accounting, finance, warehouse mgmt., manufacturing and healthcare focused applications - many in ColdFusion - all with only my lowly business degree and minor in accounting.
I'll admit that I have had computer science courses here and there but aside from a semester of java I did not learn much about object oriented development while in school.
Stop the snobbery and let this post die. The comments on this thread are starting to look more and more divisive each day. If you want to lose developers to php, ruby and .net then this is a sure fire way to alienate a large cross section of your population and push them to go find something else.
Enough is enough!
sorry, I know, I tend to be what you call "snobbery" and I let the thread die, promised.
Though let me say that I just read your earlier posts here, they're great, really!
My goal was not to be technical, but professional. What does that mean? I learned Java and (Turbo) Pascal, both at univ..
I know Java, JSPs, Hibernate, EJBs, Struts, Spring, whatever, I have Certifications acquiered as Java and Web Component Developer, I didn't say a word about it, because
why shall I say, oh, in Java, JSPs and Servlet, I develop "against" interfaces, use inheritance, love polymorphism, abstract classes, object models, try to handle database pooling, transactions and the impedance mismatch with Hibernate and all the rest.
To a Java/Servlet developer this is staff of life, hey, I even was a former Macromedia Certified Dev, but I don't give a s... on this, believe me.
The goal is to have content clients, performing apps and good CF developers, but why not recognize the fact that the abstraction of the cf engine alleviate a developer of coldfusion from knowing this things?
Cheers
oscar
The HAS to be one of the finest turns of a phrase I have heard in a long while.
Bravo!
It is very interesting to see what was the focus of my studies in college being played out in the CF community. That being the authoritarian personality, conformity and orthodoxy as related epistemology and social and developmental psychology.
Absolutely fascinating.
http://homeboxer.com and http://beagletrainingguide.com
i don't like the guy at all.
I dont like him at all either.