If not OO, what then?

[Adam Presley]

In listening to the discussion it was pointed out by Mr. Helms that he
feels he cannot "do OO in ColdFusion anymore". My question is, if not
OO, what paradigm would you recommend to new CF developers, or even
seasoned developers looking for more information?

I personally come from an OO background in C++, so to me it simply
makes sense. I will say that CF is lacking in performance in certain
areas. I have written applications with good ole spaghetti code, pure
OO, procedural-based, and so on. In the end I still like to see the
problems breakdown in an OO fashion.

So what methodology are you recommending for the Coldfusion community?

[Todd Rafferty]

Correct me if I'm wrong, but I believe Hal said he cannot "do OO in ColdFusion anymore" due to performance reasons?

[Hal Helms]

I'm with you on wanting to do real OO, Adam. I came from a Smalltalk
background and it just feels like the most natural way to develop. I
didn't go through the procedural phase that many developers do. So,
what do I recommend? My focus for the last year or so is on doing
event-driven programming using client-side (JavaScript) events, using
the HTTPRequest object (Ajax) to communicate with the server. I can
handle a lot of the interaction that I previously did on the server.
Only now, it's much faster. This has INcreased my reliance on
JavaScript and DEcreased my reliance on ColdFusion. But the most
important thing is that it lets me deliver well-architected (well, at
least I think they are!) apps faster. And clients like them a lot
more.

That said, I'm not nearly as concerned as I used to be about
server-side stuff. My Ajax calls typically return partials of a page.
Instead of thinking of the page as a monolithic unit built by the
server, I see the page as a client canvas onto which I place various
elements. What I want from the server is consistency (don't make it
hard for me to do my job), flexibility (let me return stuff in JSON),
and speed. At our shop, we've adopted this event-driven way of
development completely. It takes some getting used to, but unlike OO
in CF, there's no looming wall we're doomed to run into.

Don't get me wrong: I'd LOVE to be able to do OO on the server. But I
feel this is much less important than my ability to create a
well-thought-out framework for dealing with events. That's where I'm
putting my time these days.

Hope that helps a little?

--
Hal Helms
Training, Mentoring, Consulting

[Adam Presley]

Aye, exactly what I said. So my question is what would he recommend to
the ColdFusion community? I've worked on projects with 6,000+
spaghetti code templates, and I'm not a fan.

[Adam Presley]

Oops. You answered while I was typing that line. :)

[Adam Presley]

As for AJAX and smaller bites of functionality, sure, no argument
there. But what then is your approach for managing the business logic,
domain modeling, and so on for your server side pieces that are used
by your client side? Are they simply little CFM pages that execute a
query and transform to JSON? Is there some type of structure you are
recommending?

Part of the arguments listed had to do with a deficit in strong
direction from community leaders, with too much OO theory, and "it
depends" answers. So what strategies should budding CFers look for?

I typically approach OO in CF from the standpoint that I model my
domain logically and smartly, but try not to overuse where I know CF
can't handle it. For example, I cannot, due to performance, return an
array of 1,000 bean objects from a Gateway, when I know that CF will
choke on it.

[Sean Corfield]

On Tue, Jul 14, 2009 at 11:22 AM, Adam Presley<ad...@adampresley.com> wrote:
> Part of the arguments listed had to do with a deficit in strong
> direction from community leaders, with too much OO theory, and "it
> depends" answers. So what strategies should budding CFers look for?

As one of the leading "it depends" advocates, let me chime in here...

I come from a C++ / Java background with some Smalltalk (and a myriad
other programming languages, some procedural, some functional, some
declarative - my early career was focused on compiler development and
language design!). When I started in CFML, it was already based on
Java and had components. I naturally followed my experience of using
OO as the "best" way to help solve many problems and when I shared my
thoughts it was from that perspective. I got badly burned! People
simply copied my examples and pasted them into their applications with
no understanding and when I tried to create some simple guidelines I
thought folks would understand, they blindly applied them as inviolate
rules! Argh!

So I pulled the examples out of my guidelines and started to say "it
depends" a lot and then started to push back even more emphatically on
use of the guidelines without understanding. I guess I underestimated
the "level" of development in the CF community because all of my IT
experience up to that point was around Comp Sci people building
systems with a lot of business logic and relatively little data (or,
sometimes, vast swathes of data but again mostly focused on logic to
process said data). In other words, I wasn't used to being around
people who were a) mostly self-taught b) did not have any Comp Sci
background c) dealt primarily with CRUD-based data-centric apps and d)
often knew only one language.

I've had to try to adapt my recommendations to that new world and it's
made me a bit gunshy of sounding too "definitive" about anything.

I sympathize to some extent with Hal's position, especially since he
was previously such an OO advocate in the CFML world as well, but I
think now he's suffering from what I got burned by: folks talking his
words as gospel and believing "OO is bad!" when that isn't really what
he's saying (at least, I *hope* not!). Overall, I'm much more aligned
with Brian's position and I think demonizing his advice and
misrepresenting his ideas and suggestions - however humorously - does
a disservice to CFML developers who genuinely want to learn OO
techniques.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Adam Presley]

And that I do understand, and apologize if I come off as pushing for
an answer from community leaders. For years my boss has hated for one
simple phrase: "it depends". I've been burned enough times myself in
just my career to know that a straight forward answer is not always
applicable.

Having interviewed many CF developers in the last 2 years I find that
a large majority of them simply look for someone to hand them the
answer. Please note that I KNOW this is NOT just CF, but PHP, .NET,
and all other languages, as I use them as well. So I am finding less
devs that try to SOLVE problems and more that simply wish to be given
a solution. I just WANT CF to make it work. I'll google and find
someone else's Javascript instead of learning why what they did
worked.

So a good number of the anti-{insert technology/methodology here} is
from our very own communities breeding developers that do not wish to
know WHY it works, or HOW to utilize the tools correctly that are
available.

Like you I lean toward Brian's argument. Be smart in your use of the
methodology. Purists fail to see that not every tool works for every
job. That goes for OO purists, and old-school CF purists.


On Jul 14, 2:01 pm, Sean Corfield <seancorfi...@gmail.com> wrote:

> Railo Technologies US --http://getrailo.com/
> An Architect's View --http://corfield.org/

[Hal Helms]

Well (don't tell Brian!) I actually call CFC controllers that always
return JSON structs made up of...

event: a new event to be announced such as "customerFormDisplayed"
display: the HTML to be placed on the client "canvas" as well as the
JavaScript needed to respond to user events for this part of the
client "canvas"
build: an array of files used to create the display -- typically a
.cfm file and a .pgm file containing the JS
context: the id of the element into which to place the display
displayAction: should the display replace, append to, or prepend to
the context element?
data: a struct of data that may be needed on the client
timestamp: used for client-side timeouts, polling, etc.
controller: the controller that processed the event. In the case of
one controller calling another, it's the initiating controller
originatingEvent:what event spawned this response?

As to the business logic, placing so much of the interaction on the
client really does simplify the server code. I built a small,
lightweight server framework, although one could easily substitute
ColdBox, Model Glue, Fusebox, Mach-II, etc. Personally, I'm weary of
the front controller pattern.

I've built some pretty sophisticated apps with this and haven't needed
to go deeply into domain modeling. In fact, as I stated, I feel
prohibited from doing deep domain modeling given the problems with OO
in CF.

On Tue, Jul 14, 2009 at 2:22 PM, Adam Presley<ad...@adampresley.com> wrote:
>
> As for AJAX and smaller bites of functionality, sure, no argument
> there. But what then is your approach for managing the business logic,
> domain modeling, and so on for your server side pieces that are used
> by your client side? Are they simply little CFM pages that execute a
> query and transform to JSON? Is there some type of structure you are
> recommending?
>
> Part of the arguments listed had to do with a deficit in strong
> direction from community leaders, with too much OO theory, and "it
> depends" answers. So what strategies should budding CFers look for?
>
> I typically approach OO in CF from the standpoint that I model my
> domain logically and smartly, but try not to overuse where I know CF
> can't handle it. For example, I cannot, due to performance, return an
> array of 1,000 bean objects from a Gateway, when I know that CF will
> choke on it.

Hal Helms
Training, Mentoring, Consulting

[Sean Corfield]

On Tue, Jul 14, 2009 at 12:12 PM, Hal Helms<hal....@gmail.com> wrote:
> I've built some pretty sophisticated apps with this and haven't needed
> to go deeply into domain modeling. In fact, as I stated, I feel
> prohibited from doing deep domain modeling given the problems with OO
> in CF.

Railo apps based on Transfer ORM run up to 10x faster than on CF8 and
I'm seeing people report a similar speed improvement in CF9 Beta (I
generally see Railo running code 3-4x faster than CF8 but
Transfer-based apps are extremely CFC-heavy so the speedup is more
dramatic).

Is an order of magnitude performance boost sufficient to assuage some
of your concerns? If not, what would it take for you to leverage CFCs
more?

--
Sean A Corfield -- (904) 302-SEAN

Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

[Adam Presley]

Interesting system. And this is an example of where you thought
through the problem and came up with what you feel is an elegant,
maintainable solution. In the end, OO isn't everything. It is a good
way to organize code, but as I've told my bosses: "You can do all
procedural for all I care, as long as it's organized!".

Looks nice.

[Hal Helms]

Don't fall for that "OO purist" stuff, Adam. The reason we end up NOT
doing OO in CF is not because there's something wrong with OO (there's
not!) but because CF just is too non-performant. So we HAVE to break
out of the OO paradigm and mix and match OO and procedural.

Of late, I've been working with Ruby on Rails (Oh, the humanity!) and
I can tell you there's no idea of having to compromise the OO paradigm
because the language does an excellent job of supporting OO. In
fact,in many languages, you can change the language itself, allowing
you to add in the features you need. That's possible exactly BECAUSE
the language really is OO to the core.

Possibly CF9 will solve all problems. I'll...uh...believe it when I see it.

On Tue, Jul 14, 2009 at 3:08 PM, Adam Presley<ad...@adampresley.com> wrote:

> Like you I lean toward Brian's argument. Be smart in your use of the
> methodology. Purists fail to see that not every tool works for every
> job. That goes for OO purists, and old-school CF purists.

[Hal Helms]

A couple of years ago, I had a real "Aha!" moment when it dawned on me
that, due to my own prejudice (for server-side languages and against
JavaScript), I was missing an opportunity to create much better user
experiences. So, holding my nose (I REALLY didn't like JavaScript back
then), I dug into JS until I felt I really knew it. I now really LIKE
the language. That led me to events and it transformed the way I write
code. jQuery was really the icing on the cake, making it very easy to
manipulate the client canvas.

--

[Hal Helms]

Note to self: You REALLY should stop using "really" so much...

On Tue, Jul 14, 2009 at 3:28 PM, Hal Helms<hal....@gmail.com> wrote:
> A couple of years ago, I had a real "Aha!" moment when it dawned on me
> that, due to my own prejudice (for server-side languages and against
> JavaScript), I was missing an opportunity to create much better user
> experiences. So, holding my nose (I REALLY didn't like JavaScript back
> then), I dug into JS until I felt I really knew it. I now really LIKE
> the language. That led me to events and it transformed the way I write
> code. jQuery was really the icing on the cake, making it very easy to
> manipulate the client canvas.

--

[Hal Helms]

An order of magnitude would entice me, yes, although I'm highly
skeptical of these claims. It seems every new version of CF is touted
as "x times faster!" But yes, I'd certainly be willing to reconsider
my position if performance is drastically improved. I'm working on an
app now that I'm going to try on Railo. I'll be interested to see the
differences in performance.

--

[Adam Presley]

Oh I agree. I've spend the last 2 years refining my Javascript. I love
the language. There are so many powerful aspects to it. jQuery is
greatness, and I love Ext.

[Brian Meloche]

I think we're still completely missing the point.

What is OO in ColdFusion? What is not? Who cares?

Are we trying to fill in some magical OO checklist that we make our CF code behave in the 127 different ways and that is OO?

It's not an all or nothing. It's not a do it here and not there.

So OO can't perform in CFML apps.  Let's take that as a given, regardless of performance increases.

In trying to build things OO style in CF, what problems are you trying to solve? What problems do you cause yourself by building OO in CF? I'm asking rhetorically.

Now, take a step back... put aside theory and step into Brian M's Pragmatic CF world. Theory is theory, not fact. I deal with fact.

I need to solve x problems. How can I solve those problems without creating other problems?

My point is that when you try to make ColdFusion be an OO language, you're missing the point.

When you try to make doing OO in ColdFusion easier by using this framework (your preferred controller framework) or that one (ColdSpring/Lightwire/others with built-in DI/IOC/AOP), or this one (Reactor/Transfer/DataFaucet) you're missing the point.

What strategies do you use to solve your architectural problems?  Do you solve those problems effectively? If not, what can you do to improve them?

Solve problems. If pure OO, in theory, solves all of your problems but causes too many new issues for you, then what can you change to make your code "OO-like" and solve most (or all) of your problems without causing new ones?

I think the problem right now isn't to OO or OO at all. That misses the point.  It doesn't matter whether you are OO or that you are procedural or some mix... in fact, hanging a name on your coding style is a load of crap to me... and misses the point.

Stop trying to give your programming style a name.

Identify your problems most effectively, solve them, and do it in such a way that is maintainable, scalable, performant and doesn't require a PHD.

You can get ColdFusion 80-90% of the way to OO without the problems pure OO causes, and I wish we'd start trying to focus on that, rather than hanging a name on whatever the solution is.

It's about time I started blogging on all of this crap. It was said here and in the podcast no one is doing that - that no one from the leaders of the community is taking a non-OO approach. I think I'm close to figuring it all out, if I just had enough time to tell everyone what I've figured out and it's time I started sharing that with the rest of the community.

And for that, it's not "non OO". It's pragmatic ColdFusion development. I'd like to call not OO, but OI (Object Influenced) ColdFusion, and I guess I'll start talking about that in the days and weeks to come.

Sincerely,

Brian Meloche
brianmeloche at gmail dot com
Producer and Host, CFConversations Podcast
http://www.cfconversations.com
Blog: http://www.brianmeloche.com/blog/
Adobe Community Expert:
http://www.adobe.com/communities/experts/members/BrianMeloche.html
Twitter: http://twitter.com/coofuushun
User Group Manager,
Cleveland ColdFusion Users Group,
http://www.clevelandcfug.org

[Brian Meloche]

LMAO - I guess I fell into peer pressure there and "named" my style.  Well, anyway, OI ColdFusion, to me, is the goal.

I'll also add that the way Hal's solving it, by treating CF as largely a data transmitter and having that data sent to the client and the client solves it in OO... works.

Sincerely,

Brian Meloche
brianmeloche at gmail dot com
Producer and Host, CFConversations Podcast
http://www.cfconversations.com
Blog: http://www.brianmeloche.com/blog/
Adobe Community Expert:
http://www.adobe.com/communities/experts/members/BrianMeloche.html
Twitter: http://twitter.com/coofuushun
User Group Manager,
Cleveland ColdFusion Users Group,
http://www.clevelandcfug.org

[Adam Presley]

And I feel "OI" is a very nice acronym. :)

On Jul 14, 2:59 pm, Brian Meloche <brianmelo...@gmail.com> wrote:
> LMAO - I guess I fell into peer pressure there and "named" my style.  Well,
> anyway, OI ColdFusion, to me, is the goal.
> I'll also add that the way Hal's solving it, by treating CF as largely a
> data transmitter and having that data sent to the client and the client
> solves it in OO... works.
>
> Sincerely,
>
> Brian Meloche
> brianmeloche at gmail dot com

> Producer and Host, CFConversations Podcasthttp://www.cfconversations.com

> Blog:http://www.brianmeloche.com/blog/
> Adobe Community Expert:http://www.adobe.com/communities/experts/members/BrianMeloche.html
> Twitter:http://twitter.com/coofuushun
> User Group Manager,

> Cleveland ColdFusion Users Group,http://www.clevelandcfug.org

> > On Tue, Jul 14, 2009 at 3:29 PM, Hal Helms <hal.he...@gmail.com> wrote:
>
> >> Note to self: You REALLY should stop using "really" so much...
>

[Hal Helms]

Pronounced as "Oy!". As in, "Why do my CFCs take 45 secs to
instantiate? OI!" When combined with the "Value Added Yardstick"
(VAY) measurement tool for judging developer productivity, one hears a
lot of "Oy Vays!"

[Brian Meloche]

LMAO - OI (Oyy) it is! :-)

Sincerely,

Brian Meloche
brianmeloche at gmail dot com
Producer and Host, CFConversations Podcast
http://www.cfconversations.com
Blog: http://www.brianmeloche.com/blog/
Adobe Community Expert:
http://www.adobe.com/communities/experts/members/BrianMeloche.html
Twitter: http://twitter.com/coofuushun
User Group Manager,
Cleveland ColdFusion Users Group,
http://www.clevelandcfug.org

[Brandon Hansen]

Basically it appears that Hal likes the way that Google builds apps.
This method has really worked for them as it allows apps to be built
quicker (and we all know that all Google apps respond like
lightning).

I think that we are all just very wrapped up in that THIS IS HOW IT
SHOULD BE.

My feelings are that the reason that you do something is because it is
not only effective and efficient now, but will be in the future. Can
other dev look at your work and jump right in? Can your app be
refactored and transformed quickly? If not, you are doing it wrong.
It is as simple as that.

OOP was created to solve a problem. If it makes more problems than it
solves, you are really going against the purpose of the design
pattern. On the other hand, if using OOP allows you to solve the
problems, then use it.

Some people have said that OO in CF gives performance problems. Ok, I
will accept that. But at how high of use is that? There is a guy
that I work with that says- "Premature optimization is the root of all
evil". If we aren't writing OO because it might not hold up when we
have 1,000,000 hits per day, and we are only getting 1k hits per day,
then let's deal with it when we get to that problem. There is no
sense in trying to fix a problem that we might never even have. Don't
buy a stock pile of engines because one day your current one might
blow up.

[Adam Presley]

Great... now I'm afraid my car's engine will just BLOW up. ;)

In all seriousness, good points. Right tool, used properly, for the
right job, will have the right results.

[Brian Meloche]

Brandon,

Without going into a lot of detail that might break NDA (my company's, not Adobe), all I can say is that the thoughts expressed here come from time spent dealing with the very problem we are discussing. The object creation performance problem is real. It got better in CF8, but was still an issue. Again, this is not my opinion. This is fact. It's fact because I experienced it in a very real, tangible and might I say painful way. The fact that I also say it in past tense, you can assume that it's not a problem anymore, and that it was dealt with. I won't confirm or deny that part of it. :)

Sincerely,

Brian Meloche
brianmeloche at gmail dot com
Producer and Host, CFConversations Podcast
http://www.cfconversations.com
Blog: http://www.brianmeloche.com/blog/
Adobe Community Expert:
http://www.adobe.com/communities/experts/members/BrianMeloche.html
Twitter: http://twitter.com/coofuushun
User Group Manager,
Cleveland ColdFusion Users Group,
http://www.clevelandcfug.org

[tm8747a]

Out of curiosity, do you take into account people with javascript
disabled? Or do you use this "framework" of programming mainly for
projects where you don't need to support that?

[Andrew Bauer]

I am curious how the hybrid OI will pan out. Will it become the new
programming paradigm?

Also the talk about event-driven programming reminds me of the days
creating Visual Basic 6 applications (I transferred to PHP just
as .Net was released). It is rather amazing how quick web-based
programming has changed to be able to mimic application-based
programming. It won't be too long before a thin OS boots into a web-
based desktop with applications like Google docs as widgets.

[Hal Helms]

You can build your apps using "unobtrusive JavaScript" but frankly, I
think for any modern application (not necessarily a website),
JavaScript is required. When I build apps, I explain to the customer
that JavaScript must be turned on.

--

[tm8747a]

Nice to see somebody else takes that approach. When accessibility is
not a must, that's usually the path I take as well, but I hadn't heard
too many others saying they went that route.

[Sam]

Someone pointed me to this and I just wanted to add my two pennies.
Sorry if some of these points have been covered already.

The fact is Coldfusion is slow, however sensible people aren't using
Coldfusion for its speed. It's always been poor in this respect and it
probably always will be due to the nature of the language. What people
need to consider is the added value that it can offer if used
correctly. I listed the four things that immediately came to mind:

a) All languages and all projects of any magnitude require compromises
(performance against readability against flexibility). The situation
will determine the best compromise.
b) Maybe the question should be "if not Coldfusion" rather then "if
not OO"? I still like Coldfusion if used for the right reasons. These
days dynamic languages have even become all the rage. Perhaps
considering Coldfusion as part of a larger solution (including Java
or .Net) should be considered by more people.
c) It was mentioned that people come from different backgrounds into
Coldfusion. Many not from OO roots. To me though this is one of its
great assets. It doesn't result in necessarily great code but opens up
programming concepts to a larger audience. People can hopefully learn
from there. For those beginners to programming, it is likely that
speed is far from the number one factor for the projects they work on.
I would suggest they concentrate more on readable, simple code,
utilising OO where possible.
d) Lastly, people shouldn't forget the basics of programming. If code
is loosely coupled then the best approach may be to start with the
nicest, cleanest solution and (as someone has mentioned in the thread
before) then adapt the code when better performance is required. The
use of design patterns may help in this.

[ROCK]

CF developers should not think of OO as a way of life for programmers.
It would be far more useful to think of it as a collection of ideas
that CAN enhance development productivity when used appropriately.
Taking advantage of object oriented ideas like encapsulation and
inheritance does not mean you must divest yourself of everything you
learnt in the procedural world.

I think a lot of this debate revolves around best practices. When you
have to design something, whether it be a minor feature or an entire
system, we want to do a good job of it. The experience we have and the
advice of our peers is important.

Majority of the people who contribute and lead the CF community are
comfortable within an OOP world. It's a philosphy that they apply to
code. Part of this is the desire to free oneself of the complexities
of a application development. In believing that OO is better than
procedural, a lot of what is said is couched in an Object Oriented
Framework. In addition to the OOP Framework, other classes of
frameworks are employed: MVC, ORM, AOP, TDD, etc. Each one there to
solve problems that one can experience while on assignment. Each one
requires you to follow a particular discipline. EG. MVC would tell a
traditional CF programmer that the processing of the data (retrieval,
writing, manipulation) should happen at the start of the web page and
not halfway down. While on one hand it allows you to make a logical
seperation of concerns it may mean you have to give up on a more
elegant solution to a specific problem. So as a result nothing comes
for free.

ColdFusion's biggest strength is that it is designed for Rapid
Application Development of web pages. It's ability to interact with
other systems such as DBs and the filesystem with relative ease makes
it powerful. The discipline of some frameworks slows down that "Rapid
Application Development".

I certainly take Hal's point that ColdFusion is not a language that is
optimised to write a fully OO system. It can scale very badly if you
are attempting to deal with hundreds or thousands of objects. If you
want to deal with large sets of data, you would probably be better off
leaving them in cfloop and cfquery/cfoutput rather then creating an
object for each row
. That's not exactly a secret. Having said that, ORM's can certainly
speed up development.
So I don't want to completely disown objects within ColdFusion.

I think the appropriateness of OO or any other technology for the
project is determined by the following:

1. Does using this new technology simplify development or make it more
complicated?
2. Will the technology decrease the ammount of time I have to spend on
a project?
3. Is the technology robust and reliable (or at least enough for my
needs)?
4. Will maintainance be an issue?
5. Do I have or can I get the skills required to utilise the
techonology?
6. Does the technology solve the problem I am experiencing?
7. Does the techology introduce new problems that I have to deal with?

[Steve Bryant]

On Tue, Jul 14, 2009 at 2:55 PM, Brian Meloche<brianm...@gmail.com> wrote:
> And for that, it's not "non OO". It's pragmatic ColdFusion development. I'd
> like to call not OO, but OI (Object Influenced) ColdFusion, and I guess I'll
> start talking about that in the days and weeks to come.

Brian,

You inspired me!
http://www.bryantwebconsulting.com/blog/index.cfm/2009/7/17/OO-OI-Oy-Vay

(for those that don't want to read it, I basically offer a definition
for OI and argue that this may be more helpful than the more formal
term "OO").

Thanks,

Steve

[jmetcher]

A little anecdote pertaining to the desired order of magnitude:

We recently got to the first release of our new domain model for our
core product. The code base worked its way through unit testing,
integration testing, bugs were found, bugs were fixed. Finally we get
to load testing. One user, no problems. Coupla users, no problems.
Forty users, little bit of a slowdown.

Turns out we had neglected to enable lazy loading for the three
largest tables in the database. Oops.

OK, so that was a bit embarassing. The point is that the difference
between loading 10 records and loading 10,000 records was
imperceptible. Wasn't until we tried to load millions of records
that we saw anything amiss.

To me, that kind of performance makes a qualitative difference that
goes beyond the numbers. In this (Java) system, our code is much
closer to our conceptual model than our CF code can be.

Or to put it another way - one order of magnitude isn't enough. Two
or three can change everything.

Jaime