Vote NO on Prop "ORM"
May 22 2009 by 
Marc Funaro
It's probably too late. I'm sure they've already decided. But I guess we can still just "choose not to use it."
I'm talking about Adobe injecting ANY sort of ORM into the next version of ColdFusion.
Yes, I'm sure this argument has been hashed out in many a blog posting and message board. But since I appear to now be at least an occasional blogger, I might as well add my two pennies.
I would MUCH rather see the brilliant minds at Adobe STOP trying to push CF into the OO paradigm, WHERE IT CLEARLY DOES NOT BELONG. Least of all, trying to solve the hardest part about OO in ANY language -- the impedance mismatch between OO and RDBMS.
The very fact that you'll pretty much NEVER be able to use an OODB with CF should have put a stop to the OO featureset in CF EIGHT. At least with a true OO language, you have the choice -- You *could* in fact use an OODB. Not so with CF. CF works with flat file databases, desktop- and enterprise-grade databases, and yes, even Excel spreadsheets as data sources. And it does it with performance and agility. That's it's gig.
But CF is not OO. Never will be. And stuffing an ORM feature into it is a waste of the talented product developers/programmers and support staff at Adobe. They've probably already wasted the time and money to develop it. Now it's poised to cause a flood of support requests when it gets used improperly, doesn't work, or is just too slow (and that's pretty much what ORMs are best at... "slow"). And inevitably, those that don't fully understand what CF really is -- newbies, or those investigating the various application server choices for their own new ventures -- are going to take the position that CF is just "slow", because that's what they are going to see people complaining about. All because someone decided to cram half-baked OO design into a non-OO platform, right down to the data storage.
Those poor folks at Adobe that have had to deal with implementing such a bad idea... and all those poor souls that are going to have to support it. I would much rather see either improvements to the current language, or some new tags and functions. Even work on the sometimes-lame but often time-saving DHTML features would be a better use of their time, and better for the language and the platform as a whole.
And I definitely would rather see Adobe developers working on an iron-clad IDE specifically for CF (which we haven't really had since CF Studio 5... but that's another rant...). What better way to get ColdFusion adoption up than to provide us with better TOOLS, not half-baked OO implementations. Bolt is coming... I'm sure it would have BEEN here if not for all the ORM development that's surely taken place. And it's too bad, because a kick-a$$ tool for CF would make it even more attractive to those still "on the fence" or considering switching. And it would certainly speed adoption by new developers -- the Daily Vitamins and Minerals of any programming language.
Truly unsettling.
Please don't misunderstand -- I don't completely ride against OO. I certainly do now more than ever before, because it's been way too hyped in the CF community. The OO features in ColdFusion are not bad, as they stand right now. In LIMITED, specific cases, they will help a developer build a better app. OO has a SMALL place in the CF world. Too small to bother with pinching off a loaf of ORM on top.
So everyone, commit right now -- don't use it. Just don't. Or, I suppose I should say, use it in some novelty app, if you seriously think it's going to save you some time (Even though it won't, not in the long run.) But whatever you do, remember what CF is good at, and stay true to that. And that means using OO when absolutely necessary, and avoiding that wonderful impedance mismatch unless you have some (amazingly, truly, concrete) evidence that using it will help your project. Commit to finding every possible OTHER way of "persisting your data", including a review of all the powerful features that enterprise-tier database systems ALREADY have, that offer truly time-tested performance and reliability, FIRST. Know that you WILL BE giving up at least some of the power in your database tier if you choose to go the OO-ORM route with CF. Don't start out saying "for this project, we're going to use OO and CF's new ORM". Because chances are really good, You Ain't Gonna Need It.
Rant Over, I suppose the Flames May Ensue Now.
Posted in ColdFusion | OO | 
10 comments
May 26, 2009 at 9:02 AM
'I don't completely ride against OO' from what I have read in your blog posts so far - yes, yes you do.
Do you really think that Bolt would be delivered already if Adobe did not incorporate ORM into CF 9? Seriously?
I would have to believe that Bolt and CF9 would be released around the same time, if not at the same time - regardless of whether or not CF9 had ORM.
There are a lot of features in CF that I do not use, but I would never assume that I would know what other customers would want/use.
If you do not want to use ORM, don't, no one is forcing you to.
If you do not want to use OO, don't, no one is forcing you to.
But, please, don't slam a feature that you have not used yet in a production environment.
May 26, 2009 at 11:24 AM
I don't do much OO and I don't use an ORM. Even so, I am glad that we have a selection of good ORM solutions available for ColdFusion.
If/when I have a project for which OO is a good fit, I am glad to have the tools available for it. For the right sort of project, I would absolutely use an ORM and an OO framework. I am grateful to have them available.
I see that you are trying to be a countervailing force to the dominance of ColdFusion blogging about OO development, but perhaps a more balanced approach might be more helpful.
May 27, 2009 at 8:27 AM
Since it seems like you're not aware of it, CF9 is integrating with Hibernate, which is a Java ORM that is very widely used and has tens of thousands of man hours invested in it. So Adobe isn't "developing" an ORM. They're just wrapping something that already exists and has been proven to work extremely well.
And for someone who, I assume, has never used Hibernate, you seem to be making a lot of sweeping statements about it. You might want to actually use it or read something about it before you disparage it?
May 27, 2009 at 11:07 AM
@Scott,
I'm not sure I can respond without writing another novel, and I'm desperately trying to reign in the lengths of my posts and comments because I don't *want* to be a pedantic windbag... so bear with me! :)
-- I agree with you -- I have made some rather controversial statements against OO, which require both follow-up (with supporting evidence) and proper clarification... with less emotional (read: frustration) elements. That follow-up will come as soon as I can write it, and I hope you'll stick around :) In the meantime... I concur that it appears that I ride against OO. I've muddied things up and need to clarify my thoughts on the blog.
-- I agree with you -- I have passed judgment on the upcoming ORM feature ahead of its release. The proof of it's performance will be in the pudding, of course.
I think we'll continue to disagree on two points...
-- Yes, I *do* think that if the brainpower that's been put towards the additional OO-based features had been spent on Bolt -- in other words, if Bolt had been a true priority much earlier on -- that we'd have version one in our hands right now. And I still firmly believe that the lack of a well-supported, Not Free, true CF IDE has hindered the growth of CF. Every other language seems to have a mature de-facto IDE... with CF, it's been "install Eclipse, then get this plugin... see if you can get it to work, and then have it get in your way quite often..." And lets face it, new/non-CS people that want to get into CF really do NEED a quality IDE to help them along.
I am *not* slamming Mark Drew here. His work on CFEclipse is a tremendous undertaking, and it's really too bad Adobe didn't see it. But he's just one person.
And how long after the concept of Flex, did it take them to come out with the first Flex builder? Seems to me that when Adobe makes something a priority, it HAPPENS. The first Flex builder, albeit expensive, helped "launch" the product line/technology. CF could have used that boost - had they put emphasis on it, we'd probably have a well supported, mature IDE by now.
Perhaps my argument should be "A CF IDE is long overdue", regardless of the ORM/OO positions I've taken. Sometimes, though, it just seems surreal --I sit here every day with the various quirks and BS that I run into with Eclipse, trying to get my work done... meanwhile, Adobe is applying resources to OO/ORM features instead (and perhaps a few other things the CF community at large would not consider a priority). What good are the features of this language if my IDE sucks and I can't efficiently write the code for the features we already have? I would gladly PAY for a good IDE, and I cannot be alone in this feeling, can I? Perhaps I am...
-- As far as whether or not to USE OO/ORM, of course nobody's forcing us to. But the current feels strong, and my concern is that developers (especially us non-CS people, or newbies) will (mis)use it instead of leveraging what the database is designed to do for them, or in leiu of learning good SQL. And I think it has real potential to persist or enhance the ideas that:
1. CF is a poor product (a "bloated turd", as it was called by one responder on reddit), when the ORM can't scale;
2. That CF developers aren't "real" developers, because they can't SQL-code their way out of a paper bag;
3. We're just adding another set of tags to our "x-tagger" repertoire;
4. We're going to hatch a whole slew of CF developers that think about the data first when building an app -- "Hey, this layer can totally take the tables I create in the db, and write CF code for me" -- hence, we can start by writing our tables, let reactor generate the code, and then we'll slap a UI on top to talk to Reactor. This is backwards. HOPEFULLY I'm wrong about this, but I just have this feeling that it's what is going to happen.
I implemented Reactor on three separate projects, and in two of the three cases it had to be removed because of performance issues under load. Now, it is entirely possible that (1) I used it wrong (though truly, I think the design was sound), and (2) that Adobe will do such a good job that we'll end up with an ORM that performs as well as using straight SQL and leveraging the individual features that each unique RDBMS has to offer (that would be a feat nobody's achieved yet as far as I can tell -- unless all the problems that come with the O/R mismatch *have* been solved). In the third case, I am absolutely confident I could have written the SQL by hand in only a little bit more time, and there's an entire layer of bloat removed from my app. THIS IS NOT TO SAY that my app is any less organized or maintainable.
My experience with Reactor, when it was time to put it under load, was, "Oh, for the stuff that's not performing well, you can always write db-specific queries". My response to that was... Well Then, Why Don't I Just Do That, and avoid ever having a performance problem in the first place (and use the full features of the database tier in the process)?
It's just a feeling and my own personal opinion (of course), that for a large majority of those currently using CF or venturing into it in the future, the ORM feature is going to cause more problems than it solves. We're not assembly workers putting pieces of something together, we're programmers, and we should be thinking about the code we write.
I will never say I can't be persuaded, of course :)
@Steve:
I'm not necessarily setting out to "BE" any sort of "force". But given the number of responses in at least partial agreement with my (albeit lengthy) posts, I think we can agree that there does need to be another point of view, expressed with equal volume. Hopefully these conversations WILL prompt other semi- or non-OO CF developers to blog about how THEY are solving problems... about how they are accomplishing the goals set out by OOP, in a non-OO way. I think they need to be heard. And the balance you seek in my posts will hopefully come as a result of me figuring out where I really am on some of these positions, clarifying, and yes, not being so stream-of-thought about it all. I don't disagree with you -- balance on BOTH sides is needed, and (sincerely!!) there are elements of OO I still embrace, and am therefore grateful to have them in my repertoire. More to come on that.
@Brain:
I'm honored to have you here... thank you so much for taking the time to comment.
No, was not aware that the ORM was based on Hibernate... I only saw that the ORM was part of the next release. And YES, I agree -- I've made some sweeping statements about THIS PARTICULAR ORM implementation, without ever seeing it.
But I'm not sure this really changes my position much, other than to say that it has a better chance of "success" than starting from scratch. (By "success", I simply mean, not being as buggy and error-prone as a version-one feature.) But I'm sure there's still been a substantial investment in resources, to create this "wrapper" for Hibernate. And I would have loved to have the solid IDE instead. :)
I guess this is the biggest clarification I need to make here, and what should have been the primary position: My argument is not "the new ORM in ColdFusion is likely to suck." Especially if it's built with a mature product (product?) like Hibernate, I'm sure the feature itself won't be any worse than any other ORM. But that's just the point -- it's still an ORM, and it's still going to bring along all of the problems that using an ORM brings. I don't need to go over all of the problems that EVERY ORM has -- I'm sure you know them, or one can Google to their hearts content about the "impedance" issues. For those that are not familiar, I think this article describes it best (but baby, it's LONGGG):
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
Even if you don't read the whole thing... Reference the "Summary" at the bottom, and you'll THINK (based on the sensationalized blog post titles and some of the more emotional parts of my rants) that I'm completely in favor of #1 -- abandonment: Stop dealing with objects, write good SQL, and you won't have a problem storing your data.
Rather, I guess I'm much more in favor of #3 -- Manual mapping -- again, in the context of ColdFusion, for the majority of CF developers, who (someone please admit??) just won't need an ORM.
But my concern is, many will not be able to contain their joy, and every single app, large or small, is going to try and use the ORM. In fact, projects that really don't need OO are going end up with objects TO FULFILL THE NEED to use this new feature. There'll be a layer built between the ORM and the app, for good measure. ActiveRecord will become the norm - Person, save yourself. Invoice, save yourself. The "persistence layer" will take care of it all. Bloat and confusion in what would otherwise be a straightforward, fast CF app is could be the result. Hence, I think at the very most, this new feature should have been a specific add-on, perhaps only for CF9 Enterprise. (unless it is??)
The recurring theme I think I'm seeing, based on the responses to date, is that OO really shines when you have a large team, and a large project. That screams CF Enterprise, and I wonder -- perhaps some of these features are best included only there. I'm not sure I fully agree with my own statement -- it's another stream-of-consciousness thing. ;)
I need to admit my mistakes here... It was wrong of me to say use the new ORM only in a novelty app. If I'm going to admit that OO really shines when the project and team is large, then ORM belongs right there with it, obviously. I'd still take an SQL guru being heavily involved in a large project over the code generated by an ORM any day, but maybe in the world of objects, that's just not a realistic stance. I'm not a Computer Science major, so I'll probably never get to be involved in such large projects. Which means my projects are probably going to be small to mid-sized, and it's there that OO, and by association the ORM, (seem to?) become less relevant, less required. And that's where all this started... for those CF'ers just like me, there needs to be more voices in the crowd saying "hey -- there ARE other ways of doing this, that are not nearly as involved, will accomplish the same goals, perform better, etc. etc." -- don't let the presence of OO-like features, and the endless blogging about CF and OO from the CS Majors, put too much pressure on you.
I stand by my YAGNI statement at the end. How many CFers are working on huge, complex projects in even medium-sized teams? Compared to the sole developer working as the only "web guy" in a company, or, like me, a single developer working for multiple clients under his owh shingle? What *are* the chances they aren't going to need it? There's more of US, I think (yeah, I need actual proof of that...) and as a result, many many CFers "AGNI". If even one person makes the same mistakes I have, and starts to feel like these things "just should be a part of every project because that way it's there when I need it", then that's one person too many. But again, I've gone beyond the original post's intent here. (Sorry!!)
What's awesome -- the CF community seems much more capable of "disagreeing without being disagreeable" than the programming world at large. Even when encountering someone making relatively unclear inflammatory statements like i have so far :)
Thanks again, everyone. Even if I'm not the best writer, this has fostered some excellent discussion... I hope we can all agree on that.
May 27, 2009 at 11:30 AM
@Mark - CF and Bolt are 2 completely different products, with 2 completely different development teams. Your argument does not really hold a lot of water because every other product can make similar claims about every other product.
Using your logic, one could argue that every other product Adobe develops is what has held Bolt back. Why do we not have Bolt? Blame Acrobat Reader or PhotoShop or Flash Player. Each of these could have had their 'brainpower' funneled into Bolt and it could have been done already.
Sorry, I do not buy into the fact that you _need_ a Cf specific IDE to write good code. Notepad would do just fine. I also don't buy into the fact that people shy away from CF because there is no dedicated IDE. Is there a dedicated IDE for PHP?
I share your frustrations with Eclipse. However, did you know that Bolt is based on Eclipse? So really what you will be doing is substituting Bolt for CFEclipse. No real big difference there.
As for your issues with ORM, I think, once again, you are looking for a magic bullet. No ORM (that I know of - I am just getting my feet wet with Hibernate) will completely meet your needs if you have complex queries that need to be done - so you will still need to learn SQL syntax.
I know some very good developers (CF and other languages) who cannot write a coherent line of SQL. SQL is but one tool we have has developers. You need not be a master at it to be a good Cf developer - does it help? Yes. Is it required? No. I'd rather let a DB guy write a complex query for me than try to muddle through it on my own.
Anyone who would start the project development with ORM most likely would have started the 'wrong' way even if ORM was not an option.
Just because some might misuse a tool does not mean that the rest of the community should not have access to that same tool. To follow that logic, we should not have <cfquery> because I have seen some abominations wrapped in a <cfquery> tag.
May 27, 2009 at 12:51 PM
@Scott:
You make a fair point about them being separate products. And, I see your position that I'm probably just dead wrong on this, because my position and comments are based on a gut reaction...
"Here we are getting ORM/OO features useful to what (I feel!) is a relatively small group of CF users, while I can't even get my IDE to recognize that when I drag a CF file into the editor window, I want an include (or insert the myriad other things that you think the IDE should be able to do). They're writing all this stuff to write code FOR me, how about helping me write my OWN code?" It's a frustration, and I spouted it.
If I follow your logic that notepad would be just as good, then why is Adobe bothering with Bolt anyway? Why is the idea of an IDE even exist - not just in CF, but in the programming world in general? Let's toss out Visual Studio and Eclipse entirely. (I sound confrontational here, please don't take it that way... I actually had a smile on my face when I wrote it... :) I just could not see myself using notepad... the lack of code highlighting/coloring alone would be my undoing.
I don't recall saying that you "need a good IDE to write good code". If that's something I implied, it was inadvertent.
What I'm saying is, a good IDE geared towards the language you are writing in DOES make you a more *efficient* code writer. Your job is much easier. At least as efficient as what an ORM might offer me, and something I am in DIRECT contact with, practically every minute of every day.
As far as PHP not having an IDE... there isn't just ONE editor, there are SEVERAL. Google results:
"PHP Editor" : about 1,090,000
"ColdFusion Editor" : 2,910
Okay, that was funny, and doesn't prove anything, other than perhaps that I should look a the CF results and see what other editors there are, aside from CFEclipse. =)
And my parallel point -- that those just entering the CF world would find it easier if an Adobe-supported, for-sale IDE were readily available -- is something I do believe in, we'll probably just disagree on that. ColdFusion Studio 5 (and I think I started with an even earlier version) made learning CF much easier for me. It was a useful tool, and even today I talk with some seasoned CF coders who have fond memories of that app. I guess I'm thinking that if new CFers could have the same experience, maybe the adoption rate might be affected by it. And certainly existing CFers would feel supported by Adobe, and would have a real place to call, with real money having been paid, when they need help... instead of feeling like you're bugging One Guy, for free. And there's at least the *implication* that with each new update to CF, large or small, there will be a team behind the IDE releasing updates to match. I imagine it would be very hard for Mr. Drew to do it all himself - as evidenced by the lack of regular CFEclipse updates, even just for known problems. (Again... Mark has done an excellent job and and I don't wish this to be a slam!!)
As far as withholding the tool because some might misuse it - I'm sure you won't have to worry about that. I'm sure it'll be in there, for everyone, in all its glory. ;)
I just hope that when people DO misuse it (they will) -- and they vent their resulting frustration -- that the community will remain kind and open to them (as you all have been with me!!)... and stand ready to counteract all the CF-slammers when they use it as their additional proof that "CF Sucks". (I know, perhaps we shouldn't care what they think... but getting "sucks" attached to your technology in any substantial sense, even if not true, does affect the reputation of it. And we DO care about CF's reputation at least a little, don't we?) I know... I worry to much about that $h1t :)
I'm appreciative of this debate - it's helping me keep perspective. I owe you a beer for sure.
May 27, 2009 at 1:13 PM
Weird...I cannot find a link anywhere on php.net that points me to an IDE that was written by the same people who wrote PHP itself.
What I find puzzling about your argument is that I have heard many times that people don;t use Cf because it is not 'free'. Yet you seem to think that a way to lure people into the fold is with another product they would have to pay for.
I understand and appreciate the benefits of having an IDE geared towards your development language or platform. But, like I said, you will not be getting rid of Eclipse. Bolt is built on Eclipse. Its kind of a wash there. However, one point you make that I agree with is that as long as Bolt is successful, it will continue and with each new version of CF, we should see updates to the IDE to match any new features.
Depending on how well you type, you may be able to code faster in Notepad than I could in even the best CF-specific IDE (my typing skills are atrocious).
As for why Adobe (or anyone else) bothers developing with an IDE - that one is easy. Developers are lazy. We want code hinting and color coding and easy ways to drag <cfincludes> on to pages and any other feature an IDE has that Notepad does not. ;)
May 27, 2009 at 1:35 PM
My guess is, you don't see a product "by" PHP "for" PHP because there are SO many choices out there already. that's just not the case with CF.
I think my position is based on a marketing mentality, having seen how really good marketing, and the idea of "get the whole package with X" will get people to spend money they might not have otherwise spent. And you and I both know, Free Software ain't free... there's always a trade-off, or you're paying someone, somewhere, eventually.
If CF9 is marketed as a soup-to-nuts platform -- something for everyone, including those lazy developers (I AM THE WORST!!!), and the whole thing is really, really polished, Adobe will make their money and all those talented people will keep their jobs. That's what I feel should happen, on a strictly philosophical level. The very fact that CF is not "free" means that extra work has to be done to make it "worth it" -- and what better way than to deliver a solid IDE, the one thing the person investing in CF is going to come in direct contact with, daily? Unless it's outrageously priced and/or poorly supported, I think that it will be a viable product in support of an already good one.
And having a good IDE is not just about how fast you can write code. It's about how quickly you can access all the other resources that help you write that code, and how proper color coding can save you extra trips between browser and IDE looking for typos, forgotten unclosed tags, et al. I can type a fairly accurate 80 WPM. what slows me down is the [write, reload, review error, find error, reload] cycle. Error checking and debugging make the IDE, and CFEclipse is all we've got. It's not awful, but it's not as good it could have been with a committed TEAM working out the bugs, finding even more ways to make it work for us, and real tech support when there's a problem... like what Adobe is hopefully (FINALLY) doing now.
Under the DRY principal, we're not "lazy" -- we're always looking for ways to become more efficient. I think that's how it's supposed to work, isn't it?
:)
LOL -- just as I was finishing, my wireless keyboard batteries went dead. I bet quite few folks are wishing I didn't have replacements!!
May 28, 2009 at 8:11 AM
Well, the object-relational impedence mismatch isn't something that ORMs cause, it's something ORMs are trying to help minimize. Because without an ORM, all you are left with is the terribly manual drudgery of writing boilerplate SQL code and manually managing the relationships within your entire domain model. I can tell you from first hand experience, it sucks. And worse, it's a time sink from hell.
Marc said "We're going to hatch a whole slew of CF developers that think about the data first when building an app -- "Hey, this layer can totally take the tables I create in the db, and write CF code for me" -- hence, we can start by writing our tables, let reactor generate the code, and then we'll slap a UI on top to talk to Reactor. This is backwards. HOPEFULLY I'm wrong about this, but I just have this feeling that it's what is going to happen."
Well, that could indeed happen, but if you aren't aware, the main use of Hibernate is not to generate code from a database. It's exactly the opposite. You create your domain model without thinking about a database at all. Then, the ORM reverse-engineers your object model and generates a database schema that can persist your model. So far from creating a "database-centered" set of developers, I hope it will finally create a set of "model-centered" developers.
An ORM also does not force an ActiveRecord pattern on you. You *can* use ActiveRecord, but you can also take the approach of using a separate DAO.
I don't think that an ORM only has benefits on gigantic projects. I would argue that the ORM integration will actually help the lone developer far more than some large team. Why? Because it can swallow a metric ton of time consuming and boring work and let you focus on the stuff that actually matters: the application itself.
Finally, using an ORM does not mean you are only working with objects. Most of the time, you will be. But Hibernate can deal with query result sets as well, and how do you know that the CF ORM wrapper won't allow the same? If you're worried about performance, wait until you see what your options are and how the system actually performs in common use cases before you lash out at it.
Jun 2, 2009 at 11:15 PM
@Marc,
I really want to be able to follow your blog (and thoughts on ColdFusion development) but it is disconcerting when it all seems to be a rant. You are doing yourself a disservice.
It isn't particularly hard to find the information about the ORM that will be in CF9. As simple Google search of "cf9 orm" will get you several results showing that it is Hibernate. Aside from what comes from the Google search, the next best source is the recorded keynote from CFUnited 2008 where it was first demoed.
CFUnited 2008 Keynote (goto minute 38):
http://partners.adobe.acrobat.com/p13978261/
Now the recording is nearly a year old and Adobe has probably refined things. But it will give insight as to what the feature might look like once it is released.
The most recent information made public about CF9 ORM features were in Terrence Ryan's cf.Objective() presentation "Advanced ORM in CF9" which, unfortunately, is not posted anywhere.
While you might not like Adobe sinking time into the ORM feature at its core it is what makes ColdFusion. Making hard things easy. The approach, merits, and usefulness can all be debated, like all other additions to ColdFusion in previous versions.