My 2 cents, not an argument, a simple view from my experience.
OOP is easier to maintain as you just change the code you are
working on that is independent of the application as a whole. If you are a
true programmer dedicated to ease of use, reusability of code, and speed,
then you do not have to compromise on any of these. Create your code in a
pre-compiled environment. I wrote C++ and VB EXE's in 1994 used to process
CGI, it ran on O'Reilly's webserver (I don't even think they make it
anymore). The code took a very long time to debug as compile time on my NT
3.51 machine was really slow, so any change took a really long time.
However, the code was scalable and allowed component based coding without
compromising speed to the end user. DLL's, EXE's, CORBA and other compiled
CGI programs are still used today. I have preferred DLL's over the years as
they are quick to write and compile. I've also done a few CORBA objects for
BroadVision 3.0, I didn't care for them as much as DLL's.
Someone said a few weeks ago "Anything under 100ms is junk"
(paraphrasing), I agree. Drop it out of an interpreted language and do it
in a compiled language. They way, you get what you want (Code reusability
and scalability), without annoying the end user is to use a tool that was
made to do the task. I used to keep an article from CFDG by Ben Forta that
yelled at people who tried to write mail servers and such out of ColdFusion.
ColdFusion is a scripting language, do not forget that, use the best tool
for the job.
ColdFusion is a great tool, I love it and use it for almost
everything. However, I still know that it was written to give quick results
and be used as a scripting language. It's also very easy to debug.
If you are writing an enterprise application with lots of logic and
business rules and you're using ColdFusion exclusively, you are cheating
your end user out of their experience most likely. Drop some logic into a
Stored Proc or a DLL, that will maintain your ease of maintenance and speed.
Don't be scared of other technologies, go write "Hello World" in VB
and start learning. That is what saves IT companies and their clients money
in the long run, informed intelligent programmers using the right tool for
the job.
Frameworks are a good idea as they introduce non-compiled language
programmers to some concepts used by compiled programmers. I am just
confused why people are trying to make a scripting language a compiled
language. If you want the benefits of ColdFusion in a OOP environment, then
use JAVA or C++. There are libraries out there that do everything
ColdFusion does. The code is easy to read and use. If you are really good
at JavaScript, JAVA is so easy to learn. It's all just function calls and
libraries. JSP has a simple scripting interface like ASP and PHP.
ColdFusion is the only hard one to learn if you know the others, because it
uses inline tags instead of <?php Or <% as ASP, JSP, and PHP use.
That's just my opinion. If you want to push ColdFusion into something it's
not, then enjoy the methodologies. Otherwise, use it for what it was made
for and runs best: simple scripted pages that display results quickly. I
love ColdFusion 5.x and below as they make development time quickly without
compromising end user display time, just what a scripting language should
do.
Jacob
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Matthew Woodward
Sent: Sunday, December 14, 2003 10:16 AM
To: [EMAIL PROTECTED]
Subject: RE: Breaking the Sound Barrier?
Thanks for the update--just a few comments from my perspective. I'm a
relative newbie on Mach-II but I've used it on two semi-large projects now
and your statement that Mach-II "yields no noticeable advantage" is a little
off-base in my opinion. *Any* framework is going to create longer
development times compared to the usual "display page/action page" scenario,
and blazing-fast code can be written if you aren't using a framework at all,
but I think perhaps your discussion is a little one-sided since it focuses
largely on--at this point at any rate--page execution times.
The true benefit of using a framework comes in code flexibility and
maintenance, not in page execution times and initial development times.
Spaghetti code can be fast to write and may be very fast to execute, but
maintenance is a nightmare. The "busy work" (as you call it) associated
with Mach-II has a huge benefit in my mind, namely that when requirements
change, or modifications need to be made in the future, they can be done
with very little impact on the existing code.
This is where Mach-II outshines the other frameworks I've tried IMO, because
if something changes, you just change the details of the event related to
that item, maybe write a new method or two, and you're done. Very rarely do
you have to trudge through hundreds of lines of code worrying about all
sorts of dependencies between pages and components. Everything is extremely
cohesive and very loosely coupled, and I've found that on the projects I've
used this on, I'm far less frustrated with changes and can make them far
more quickly and easily than I have been able to in the past. That's a huge
benefit, and also allows for a greater ROI on the application in general,
because with this extremely flexibility new functionality can be added and
old functionality can be modified quickly and easily. This means if it's
done right very rarely will an application be thrown out simply because it's
easier to start over than it is to modify the existing code base.
I don't disagree that performance is important, I'm just pointing out that
there's a LOT more to building a successful application than just page
execution time and initial development time. In my mind there has to be a
balance between what the developers have to do to build and maintain the
application and the speed with which users can access the application. In
the two applications I've done with Mach-II, even the most complex pages
come in at under 1000 ms under a decent user load, and most pages load in
300-400 ms. That's extremely acceptable in my mind. Lowering that page
load time at the cost of abandoning something that makes my life as a
developer SO much easier and thereby saves my company money just isn't a
good tradeoff IMO. If faster performance is absolutely necessary, hardware
is cheap--development time typically isn't.
I guess my main point is that we of course always have to be mindful of the
choices we make and how they impact performance, but the choices we make
have a far wider impact than just performance. If we develop something
extremely quickly that has astoundingly fast performance but we do so at the
cost of code flexibility, then we're doing everyone involved--both users and
the people paying for the development--a pretty big disservice.
Matt
-------------------------
Matthew P. Woodward
[EMAIL PROTECTED]
AIM: CaptainJavac
http://www.mattwoodward.com
----Original Message Follows----
From: S.Isaac Dealey <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Breaking the Sound Barrier?
Date: Sun, 14 Dec 2003 01:52:37 -0600
It's that time again, time for the 2nd installment of framework
comparison statistics. Both my previous article with comparisons of
Fusebox 3 and the onTap framework, and my latest article with
additional information about Mach-II can be found here:
http://www.turnkey.to/ontap/docs/index.cfm?netaction=articles
Assuming of course that I don't put you all to sleep. ;)
s. isaac dealey 214-823-9345
team macromedia volunteer http://www.macromedia.com/go/team
chief architect, tapestry cms http://products.turnkey.to
onTap is open source http://www.turnkey.to/ontap
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
_________________________________________________________________
Cell phone 'switch' rules are taking effect - find out more here.
http://special.msn.com/msnbc/consumeradvocate.armx
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
