Reactions to "ColdFusion and OOP - Match Made in Heaven or Long Road to Hell"

[Clark Valberg]

.

[Christian Ready]

Thank you Gentlemen for holding this discussion both on the audio
recording and in this forum. I think it's long overdue and if nothing
else, reinforces that I am not alone in my struggle to understand and
implement OO in CF. Like Ben, I feel that in my gut there is a
benefit to using OO, but at the end of the day, it's still very much a
challenge. I've always known intellectually that I am not alone but it
is so helpful to have that feeling validated like this. I look
forward to the next recording!

[Sean Corfield]

Yes, it's very important not to lose sight of just how darn hard it is
to adopt an OO mindset if you're used to procedural thinking. People
find the same problem trying to learn functional programming ("What do
you mean, there's no loop construct?").

I started down the OO road in early '92 with C++ and I struggled a
lot. I was lucky to be around some *really* smart, experienced OO
people and the best learning experience for me was a contract at
Vodafone UK under the tutelage of two Smalltalk guys. I learned more
in that ten months than in many years (either side).

CF's inherent "sole developer" environment (for many CFers) is a huge
obstacle to learning better practices unfortunately...

[Marlon Moyer]

Sean,

It might also be considered that CF shouldn't be the language in which
to learn OO. Other more OO oriented languages like smalltalk, java or
ruby might be better learning platforms.

[Sean Corfield]

On Tue, Jul 14, 2009 at 12:09 PM, Marlon Moyer<marlon...@gmail.com> wrote:
> It might also be considered that CF shouldn't be the language in which
> to learn OO.  Other more OO oriented languages like smalltalk, java or
> ruby might be better learning platforms.

Well, based on all the languages I've worked with - and the in-house
OO training I've done over the years - I'd be inclined to say learning
OO is language agnostic (or *should* be!) - although each language
tends to develop a handful of patterns intended to address certain
limitations (e.g., some J2EE patterns arose purely because of
limitations with EJBs). Design patterns in general are language
agnostic and OO in general is as well. In my opinion :)
--
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

[Hal]

Amen, Sean. I was similarly fortunate to work with really smart
programmers (also Smalltalkers) and their experience saved me
countless frustrations.

On Jul 14, 3:05 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> Yes, it's very important not to lose sight of just how darn hard it is
> to adopt an OO mindset if you're used to procedural thinking. People
> find the same problem trying to learn functional programming ("What do
> you mean, there's no loop construct?").
>
> I started down the OO road in early '92 with C++ and I struggled a
> lot. I was lucky to be around some *really* smart, experienced OO
> people and the best learning experience for me was a contract at
> Vodafone UK under the tutelage of two Smalltalk guys. I learned more
> in that ten months than in many years (either side).
>
> CF's inherent "sole developer" environment (for many CFers) is a huge
> obstacle to learning better practices unfortunately...
>
> On Tue, Jul 14, 2009 at 9:08 AM, Christian
>

[Will Wilson]

A very interesting listen, thank you all for composing this.

I'm sort of sitting on the fence with this discussion. I spent a lot
of time trying to get OO, and I experienced that coding block that a
lot of people are encountering, since the right, or better, way of
doing it was far too complex and often outweighed the benefits.

Like Ben, I gave up on my pursuit of OO purism. However, I can't say
it was a wasted experience. One of the best things I gained from it
was the idea of code reuse and eliminating repetition. This was the
reason I started using ColdFusion in the first place. Even though my
initial websites had no business logic, the fact I could include a
generic header/footer on each page was a huge selling point.
Furthermore, using Fusebox was a great way to maintain the code I
wrote - because inevitably I would have changes, and having a document
structure that I was familiar with made it extremely easy to pick up
and implement those changes. It's probably a fair argument that this
is over engineering, but for me it works.

I guess I'm swayed to Hal's argument because the complex ideas and
design patterns just aren't needed in ColdFusion. However, I disagree
that frameworks should be labeled in the same way. Frameworks, to me,
are the savour in this OO madness. They offer real benefit when it
comes to code maintainability and team management. And if I was
employing someone, my question would not be "can you OO", it would be
"can you work with the frameworks that our team already uses", because
that would have benefit.

I think what everyone is trying to move away from is traditional
spagetti code, and frameworks can do this a lot easier than OO for
ColdFusion. If I was given 3 projects - one as spagetti, one in a
framework, and one in OO, there would definately be 2 that would drive
me insane. I think developer would do better making sure their code is
cohesive, well organised (and MVC is a great way to do this) and
performing well, instead of blindly following the 'goodness' that OO
promises.

[Will Wilson]

I think I might have moved off the fence there :)

[Henry Ho]

The audio discussion was fun to listen to, thanks! It seems like it
all comes down to two points:

- Performance of objects instantiations in CF is slow (still slow as
of CF8)
- Most CF web app needs no OO

I'm now working on my 2nd CF project in OO, and I actually feel quite
comfortable with it. It performs relatively okay on my dev machine
(with CF8 dev edition + MS-SQL Express). My only concern is how fast
will the app be once deployed. *finger crossed*.

If your data oriented web app is fine using procedural and post-back
(w/o MVC frameworks and stuff), keep using it! Is fine, really. :)

The OO concept takes years to grasp. There's no learning OO in 24
hrs, no shortcuts. OO takes time to learn, and mistakes have to be
made and then one can realized the benefits of doing OO or design
patterns make sense. No pain, no gain!

Frustrating part seems to be coming from...

- web developer who didn't hear about OO and now forced to learn OO
'cause of the conference and/or functions from new CF version, feels
missing out and incompetent.
- the CF MVC frameworks? We only have, a handful of MVC frameworks.
Compare to JAVA, we're already lucky! :)
- decision making of how to do OO "the right way"? There's no right
way, but there are often a better way than yours (with different trade-
off's)

My colleges and I are now re-evaluating the MVC frameworks that we
tried. Maybe one day we will get rid of them altogether if their
benefits don't justify with their costs.


Henry Ho
http://henrylearnstorock.blogspot.com/

[Brian Meloche]

One other frustration... object creation performance.

(Fictional) Scenario: So you learn OO, you do things by the book and build what you think is a great CF application using OO. It's certainly nice looking code, albeit a lot more of it than you would have done back in procedural days. It was a long project, but you learned a lot. Your project goes to production, but word isn't quite out yet, and you're now adding new stuff. Then, your site finally starts getting traffic after getting digged, slashdotted, twittered and on CNN... and boom... it happens. You get performance issues. You work on it the standard ways: Memory, hardware, database, caching, static content techniques, and you improve things... but the underlying performance issue remains.

Now, mind you, if you never get into a situation where performance becomes a problem, you're probably unaware or it doesn't seem like a problem.  However, if you ever do... it's a big problem... the kind of problem that many, I suspect, migrated away from ColdFusion because of the issue. That's conjecture, but it doesn't help the perception of ColdFusion of not being a serious language.

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

[Sean Corfield]

On Tue, Jul 14, 2009 at 4:48 PM, Brian Meloche<brianm...@gmail.com> wrote:
> Then, your site finally starts getting traffic after getting digged,
> slashdotted, twittered and on CNN... and boom... it happens. You get
> performance issues.

You mean you didn't load test before launch? Hardly OO's fault...

[James Allen]

That is a very good point Sean. Something I haven't looked at yet for the
.com we are launching next month that uses OOP and Transfer etc.

Have you got any recommendations on online services etc or techniques for
load testing?

---
James Allen
E: ja...@jamesallen.name
Blog: http://jamesallen.name
Twitter: @CFJamesAllen (Coldfusion / Web development)
Twitter: @jamesallenuk (General)

[Sean Corfield]

On Fri, Jul 17, 2009 at 2:27 AM, James Allen<sling...@googlemail.com> wrote:
> That is a very good point Sean. Something I haven't looked at yet for the
> .com we are launching next month that uses OOP and Transfer etc.
>
> Have you got any recommendations on online services etc or techniques for
> load testing?

There are a ton of tools for this, some free, some expensive.

JMeter, Apache Bench are free and Microsoft has something free too I
believe (WAST?).

Paessler make a commercial tool that Mike Brunt loves.

If you're on a Mac, you already have Apache Bench (it's the ab command
in Terminal) and that can generate a fair bit of concurrent pure load
but it isn't scriptable so you can't replay "scenarios" easily (you
can write a shell script that chains multiple ab requests but it's a
pain).

[Henry Ho]

http://loadimpact.com/

Henry

[martin t.]

I am really new to programming and Coldfusion. I do not have any real
background in neither procedural nor oo programming.
I am observing that most of the programming landscape is already oo
and that the next thing on the horizon is functional programming.

It does make sense for me to learn oop to stay relevant as a hopefully
successful developer in the future that is interested in learning
more doing languages and doing new stuff. The Alternative seems to be
to learn procedural style programming and than in some years
maintain all those legacy applications that still need to change and
for which there are no developers that can programmm in the
procedural style anymore?!

Is procedural style programming going the way of the dodo? And are
programming languages that stay procedural the next cobol?

As already mentioned i am a programming freshman, so i can't really
make an informed assessment of oop vs pp.

P.S.: There are surely better languages to begin as a dev but it's a
job requirement and the job pays the bills ;)

[Sean Corfield]

On Fri, Jul 17, 2009 at 3:55 PM, martin t.<mrt...@googlemail.com> wrote:
> I am observing that most of the programming landscape is already oo
> and that the next thing on the horizon is functional programming.

I'm not sure I would say functional programming is the "next thing".
Erlang has been around since the 80's, as have many of the other
functional programming languages (I did my PhD research on this stuff
and designed and built a new functional language / interpreter to act
as an illustration of my research). Haskell, Miranda, ML, etc. Scala
is new, F# is new, but they're both hybrid languages (some OO + some
function stuff). Erlang has had a sudden, recent rise in popularity
(for some reason :)

Back in the mid-80's, as OO began to become more popular academically,
the Oxford Programming Research Group in England spent quite a bit of
time trying to backport OO features onto existing FP languages (with
mixed success).

> Is procedural style programming going the way of the dodo? And are
> programming languages that stay procedural the next cobol?

COBOL is an OO language. It was one of the first OO languages to be
standardized by ANSI/ISO in fact. True, it started out procedural but
in the 90's it grew OO features, while C++ was being designed.

There will always be a lot of procedural code out there but it will
increasingly be in maintenance rather than new development as other
styles (OO, FP, whatever comes along) dominate new software.

[James Allen]

Hi Sean,

Thanks for the pointers. I must get more into this aspect of development as
it's never something I've had to get involved with before.

I'm not on a Mac but I assume there is a port of AB for Windows? I'll have a
look for it.

Thanks again,
James.

---
James Allen
E: ja...@jamesallen.name
Blog: http://jamesallen.name
Twitter: @CFJamesAllen (Coldfusion / Web development)
Twitter: @jamesallenuk (General)


-----Original Message-----
From: coldfu...@googlegroups.com [mailto:coldfu...@googlegroups.com]
On Behalf Of Sean Corfield
Sent: 17 July 2009 19:56
To: coldfu...@googlegroups.com
Subject: [coldfusionoo] Re: Reactions to "ColdFusion and OOP - Match Made in
Heaven or Long Road to Hell"

[James Allen]

Thanks Henry – this looks good.

 

---

James Allen

E: ja...@jamesallen.name

Blog: http://jamesallen.name

Twitter: @CFJamesAllen (Coldfusion / Web development)

Twitter: @jamesallenuk (General)

 

From: coldfu...@googlegroups.com [mailto:coldfu...@googlegroups.com] On Behalf Of Henry Ho
Sent: 17 July 2009 19:58
To: coldfu...@googlegroups.com
Subject: [coldfusionoo] Re: Reactions to "ColdFusion and OOP - Match Made in Heaven or Long Road to Hell"

 

http://loadimpact.com/

Henry

[Henry Ho]

http://learn.objectorientedcoldfusion.org/wiki/Procedural_vs_Object_Oriented_Programming