Thanks for the response, Jacob. Not sure if I'd say CF is harder to learn than ASP/PHP, etc... It is xml-"ish" in comparison to the others which aren't tag based and so have syntax closer in form if not particulars to the older C syntax that's been reused by different languages ad-infinitum.
Unfortunately it looks as though the onTap framework is being nudged forcefully in the direction of CFMX, primarily by variable locking issues with CF5, since it's unable to take full advantage of variable caching in that environment. I say unfortunately not because I'm partial to CF5 in particular but because I'd have liked to see speedier results from the framework in both places for the sake of "legacy" clients and clients planning a future upgrade to MX. In the article I did mention that my test cases were intentionally inefficient: in my final article I will likely redraft the 4 different frameworks so that they are efficient and more like how you would find them "in the wild" and get performance comparisons that way as well, and I suspect that while they certainly won't be faster than individual pages using DLL's, they'll probably all be fast enough to provide a reasonable user experience for low-to-moderate traffic or with load-balancing. And finally -- don't forget that there are also hardware implications to the performance of any given application, and more/faster processors if not load-ballancing can also significantly impact user experience. For those of us who are forced to use shared hosting for one reason or another, we have little control over the hardware involved, but imho if an application is getting enough traffic to need load balancing, there ought to be a way to produce a budget for it one way or another. > 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=artic > les > 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 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
