Jared Rypka-Hauer, Lead ColdFusion Developer, Minneapolis, MN
Proud Parents of SQLSurveyor and PayPalMX
Viewing By Entry / Main
October 8, 2005 - back to top
Oy vey... frameworks... what a debate. I've been reading the Joe-and-Simon dialog over at clearsoftware.net and, I gotta say, Jerry Springer and some dude throwing chairs are all that are missing. I hear there's a screenplay in the works for a TV Movie, and that ABC is considering a daytime SOAP Opera simply called "ColdFusion."
Controversy, controversy. Over what?
Frameworks
Joe likes frameworks. Simon can't see the value. Simon has a "methodology" and Joe has Model-Glue. I have a headache (Joe, it's from the fumes, man... put the cap back on it, ok?) Actually, I don't have a headache. I do, however, have a few things to say on the subject at the center of this debate.
First of all, while discussion is good there's nothing productive to be had in senseless bickering and broken comparisons. So I'm not calling for a halt on discussing various frameworks. Productive debate is "Do we use Mach-II, MG, FB, or roll our own architecture for this particular situation?" not "Which is superior: frameworks or methodologies?"
Thing is, it's a non-debate. I mean, in all honesty, the statement "use methodologies, not frameworks" is rather like "drive a car, not a 2006 Mustang Convertable." The term "methodology" means "the study of methods" and encompases both non-frameworked applications and frameworked applications. For real... using a framework is one method used to build an application.
Someone who is a "methodologist" should be someone who studies any and all methods involved in constructing applications. A zoologist studies animals and is an expert. An endocrinologist studies the human glandular system, and is an expert. A methodologist should be someone who studies and is an expert on methods; to be credible, that someone should be an expert on all common methods and some lesser-known ones as well, and should be objective regarding their uses and those who use them.
Some methods are successful, some aren't, some are better put to use in a team environment, some work better for delivering content with static structures and some work better for intensively dynamic sites. So, using XML, a core set of CFCs, and some extensions to those CFCs... well, yeah, there's a method that can be used to build web applications. Writing everything from scratch, or porting a small set of core files from job to job and modifying them ("almost-from-scratch") is another method one can use to build web applications.
So there's really no debate going on here... it's an "argument." The difference? A debate legitimately compares alternatives. An argument, though a superset of debate, is simply an expressed disagreement over some, often nebulous, concept... where there's no legitimate alternatives up for consideration, there can be no debate.
Did I say that "frameworks vs. methodologies" isn't a valid point of contention? Yeah... ok. Just making sure.
Frameworks
A "framework" *IS* a set of core files. "Fusebox" is a set of core files. "Mach-II" is a set of core files. There's no separation between the term "fusebox" and the zip file you download. Model-Glue is a set or core files. Beyond being a set of core files there are only instructions on how to use those files to construct applications. You can do poorly at following those instructions, or you can do well. But the "doing" only comes after you have "the framework" which is "the core files".
"Using a framework" is a methodology. You can use OOP, or you can design things procedurally (in other words you can be concerned about the representation of the Problem Domain or you can be concerned about executing code). You can even write Mach-II applications that use CFCs to execute procedural code (though some would call this "a bad methodology"). In any and all cases, you're already using a methodology.
MVC or MVF?
So we're left with a bit of a conundrum. Methodology, or Framework? Confusing for a newbie, to be sure... Simon's a widely respected developer and he says not to. Joe's also widely respect and he says "frameworks are important." The big difference? Joe's ready, willing and able to encourage people to start developing at whatever level they're able and add frameworks to their tool set as they go.
Simon, on the other hand... and this is where I start getting a bit unhappy about things... is dismissive of the whole idea. It's rather unpolite (at best) to insinuate that those of us who DO use them aren't smart enough to figure out where we can improve our professional selves or not. If I thought frameworks were wasting my time, I'd quit using them. You think I use Fusebox or ModelGlue or Mach-II just for fun?
(An Aside: C'mon, Simon... give me a little credit. I'm not a sillyperson and I don't enjoy wasting my time. I'm pretty creative, too, so solving my own problems isn't usually a problem. Frameworks solve many problems all by themselves... saving me the trouble and letting me get on with my work. It's one of those "guilt by association" situations... Simon says "don't use framworks because they waste time and create problems," ergo Jared uses frameworks, therefore Jared wastes time and creates problems. Though I do use frameworks, I don't waste time, nor do I generally cause problems.)
My advice? Use all of them. Use ModelGlue, use Mach-II, use Fusebox, use ColdSpring, use Tartan. And where appropriate use a totally custom solution! And YES, there are times when that is appropriate! Learn when and where each one fits; learn to think from a perspective outside your own point of view and persue the answer to one question:
"If smart, successful people use them, what do they see and how can I tap into it myself?"
When is a Framework not a Framework?
Never.
A framework is a set of core files that can be built upon to provide a head start to something larger and more capable than the original set of files.
In other words...
Simon Horwith uses a framework.
Simon will object... this I know. But think about it. "Heres a few core files, here's how you use them." Thus, in gross generalization, starts the documentation for Model-Glue, Fusebox, Mach-II, and anything else that has core files and documentation. It's not really something that can be debated because the empirical evidence is right in front of us. This isn't Quantum Mechanics, I can see the files and know what they're for at the same time.
Whether there's 7, 17, or 70; whether or not they're modified or included or extended; there are core files, and instructions to use them in developing applications. So, above and beyond all arguments to the contrary, Simon's system is encompassed by several different definitions of "framework" I found on the 'net. From "a way to classify and express complex information" to "a basic set of rules and code used to create software" the term applies.
Expleo Explevi Expletum
"Filled" or "complete" in Latin. It's got a double meaning here. The first is simple... I'm all done ranting! Well, almost... one more point.
The other meaning is "I'm all filled up with this silly and unfortunate argument." All this bruhahah about frameworks and methodologies is causing confusion for new people and distractions for those with experience. When it comes right down to it, you're going to be improved as a developer as you play the methodologist and study what people are doing and why. Assimilate new ideas and information, and as you distill that information into the methods you use every day to accomplish your work you'll find yourself more capable and more productive.
I say learn the language, learn some good "best practices" and learn to use CFCs. Learn to code, then learn to structure and organize that code. Learn to use Fusebox and Mach-II and ModelGlue. Really, what I think people need to learn is patterns... because once you know the patterns you'll start recognizing them where ever you go... and I'm not talking about Design Patterns, though they're good as a guide.
I'm talking about overall large-scale architectural patterns... from simple composite object instances to MVC to... blah de blah de blah. Besides, once you've learned some basic patterns, just like in dancing or martial arts, you'll be able to port those same concepts to other languages and other environments.
Learn it all, because it's all just different implementations of the same thing.
Laterz!
Controversy, controversy. Over what?
Frameworks
Joe likes frameworks. Simon can't see the value. Simon has a "methodology" and Joe has Model-Glue. I have a headache (Joe, it's from the fumes, man... put the cap back on it, ok?) Actually, I don't have a headache. I do, however, have a few things to say on the subject at the center of this debate.
First of all, while discussion is good there's nothing productive to be had in senseless bickering and broken comparisons. So I'm not calling for a halt on discussing various frameworks. Productive debate is "Do we use Mach-II, MG, FB, or roll our own architecture for this particular situation?" not "Which is superior: frameworks or methodologies?"
Thing is, it's a non-debate. I mean, in all honesty, the statement "use methodologies, not frameworks" is rather like "drive a car, not a 2006 Mustang Convertable." The term "methodology" means "the study of methods" and encompases both non-frameworked applications and frameworked applications. For real... using a framework is one method used to build an application.
Someone who is a "methodologist" should be someone who studies any and all methods involved in constructing applications. A zoologist studies animals and is an expert. An endocrinologist studies the human glandular system, and is an expert. A methodologist should be someone who studies and is an expert on methods; to be credible, that someone should be an expert on all common methods and some lesser-known ones as well, and should be objective regarding their uses and those who use them.
Some methods are successful, some aren't, some are better put to use in a team environment, some work better for delivering content with static structures and some work better for intensively dynamic sites. So, using XML, a core set of CFCs, and some extensions to those CFCs... well, yeah, there's a method that can be used to build web applications. Writing everything from scratch, or porting a small set of core files from job to job and modifying them ("almost-from-scratch") is another method one can use to build web applications.
So there's really no debate going on here... it's an "argument." The difference? A debate legitimately compares alternatives. An argument, though a superset of debate, is simply an expressed disagreement over some, often nebulous, concept... where there's no legitimate alternatives up for consideration, there can be no debate.
Did I say that "frameworks vs. methodologies" isn't a valid point of contention? Yeah... ok. Just making sure.
Frameworks
A "framework" *IS* a set of core files. "Fusebox" is a set of core files. "Mach-II" is a set of core files. There's no separation between the term "fusebox" and the zip file you download. Model-Glue is a set or core files. Beyond being a set of core files there are only instructions on how to use those files to construct applications. You can do poorly at following those instructions, or you can do well. But the "doing" only comes after you have "the framework" which is "the core files".
"Using a framework" is a methodology. You can use OOP, or you can design things procedurally (in other words you can be concerned about the representation of the Problem Domain or you can be concerned about executing code). You can even write Mach-II applications that use CFCs to execute procedural code (though some would call this "a bad methodology"). In any and all cases, you're already using a methodology.
MVC or MVF?
So we're left with a bit of a conundrum. Methodology, or Framework? Confusing for a newbie, to be sure... Simon's a widely respected developer and he says not to. Joe's also widely respect and he says "frameworks are important." The big difference? Joe's ready, willing and able to encourage people to start developing at whatever level they're able and add frameworks to their tool set as they go.
Simon, on the other hand... and this is where I start getting a bit unhappy about things... is dismissive of the whole idea. It's rather unpolite (at best) to insinuate that those of us who DO use them aren't smart enough to figure out where we can improve our professional selves or not. If I thought frameworks were wasting my time, I'd quit using them. You think I use Fusebox or ModelGlue or Mach-II just for fun?
(An Aside: C'mon, Simon... give me a little credit. I'm not a sillyperson and I don't enjoy wasting my time. I'm pretty creative, too, so solving my own problems isn't usually a problem. Frameworks solve many problems all by themselves... saving me the trouble and letting me get on with my work. It's one of those "guilt by association" situations... Simon says "don't use framworks because they waste time and create problems," ergo Jared uses frameworks, therefore Jared wastes time and creates problems. Though I do use frameworks, I don't waste time, nor do I generally cause problems.)
My advice? Use all of them. Use ModelGlue, use Mach-II, use Fusebox, use ColdSpring, use Tartan. And where appropriate use a totally custom solution! And YES, there are times when that is appropriate! Learn when and where each one fits; learn to think from a perspective outside your own point of view and persue the answer to one question:
"If smart, successful people use them, what do they see and how can I tap into it myself?"
When is a Framework not a Framework?
Never.
A framework is a set of core files that can be built upon to provide a head start to something larger and more capable than the original set of files.
In other words...
Simon Horwith uses a framework.
Simon will object... this I know. But think about it. "Heres a few core files, here's how you use them." Thus, in gross generalization, starts the documentation for Model-Glue, Fusebox, Mach-II, and anything else that has core files and documentation. It's not really something that can be debated because the empirical evidence is right in front of us. This isn't Quantum Mechanics, I can see the files and know what they're for at the same time.
Whether there's 7, 17, or 70; whether or not they're modified or included or extended; there are core files, and instructions to use them in developing applications. So, above and beyond all arguments to the contrary, Simon's system is encompassed by several different definitions of "framework" I found on the 'net. From "a way to classify and express complex information" to "a basic set of rules and code used to create software" the term applies.
Expleo Explevi Expletum
"Filled" or "complete" in Latin. It's got a double meaning here. The first is simple... I'm all done ranting! Well, almost... one more point.
The other meaning is "I'm all filled up with this silly and unfortunate argument." All this bruhahah about frameworks and methodologies is causing confusion for new people and distractions for those with experience. When it comes right down to it, you're going to be improved as a developer as you play the methodologist and study what people are doing and why. Assimilate new ideas and information, and as you distill that information into the methods you use every day to accomplish your work you'll find yourself more capable and more productive.
I say learn the language, learn some good "best practices" and learn to use CFCs. Learn to code, then learn to structure and organize that code. Learn to use Fusebox and Mach-II and ModelGlue. Really, what I think people need to learn is patterns... because once you know the patterns you'll start recognizing them where ever you go... and I'm not talking about Design Patterns, though they're good as a guide.
I'm talking about overall large-scale architectural patterns... from simple composite object instances to MVC to... blah de blah de blah. Besides, once you've learned some basic patterns, just like in dancing or martial arts, you'll be able to port those same concepts to other languages and other environments.
Learn it all, because it's all just different implementations of the same thing.
Laterz!
Comments
Bravo J. Great post.
The argument between Simon's methodology and the collection of frameworks in use is rather tiring if you ask me. You are correct, it is causing confusion as I have been involved in some lengthy conversations with coworkers and colleagues about the very argument. I think the thing to remember (and you do a great job of pointing this out) is that we as developers should get a sense for architectural decisions that we find outselves making over and over on applications and learn to decipher when the application of a framework is warranted and when it is not... perhaps something homegrown is in order (for instance, with one-off applications that last a couple days).
My whole problem with Simon's approach to not liking frameworks is the overall tone he conveys in his arguments. I felt like he was placing himself on a much higher level that those of us who do use frameworks; and to be honest, that's horse shit. I am a damn good developer and I use frameworks when I feel the situation warrants the use. I know MANY good developers who use frameworks. I also know MANY who do not. I am not taking a shot at Simon per se, but rather the attitude that echoes from his posts.
I think a lot of the confusion and bruhaha comes from people misusing or not understanding the difference between a methodology and a framework. I hope people take a moment to read this post you took the time to writeup as it touches on many good points and should really bring this ongoing argument to some kind of closure, if not help people have a better understanding of this whole "discussion"... err argument. :-)
I really wish I could have attended the conference. Ugh.
Mike
The argument between Simon's methodology and the collection of frameworks in use is rather tiring if you ask me. You are correct, it is causing confusion as I have been involved in some lengthy conversations with coworkers and colleagues about the very argument. I think the thing to remember (and you do a great job of pointing this out) is that we as developers should get a sense for architectural decisions that we find outselves making over and over on applications and learn to decipher when the application of a framework is warranted and when it is not... perhaps something homegrown is in order (for instance, with one-off applications that last a couple days).
My whole problem with Simon's approach to not liking frameworks is the overall tone he conveys in his arguments. I felt like he was placing himself on a much higher level that those of us who do use frameworks; and to be honest, that's horse shit. I am a damn good developer and I use frameworks when I feel the situation warrants the use. I know MANY good developers who use frameworks. I also know MANY who do not. I am not taking a shot at Simon per se, but rather the attitude that echoes from his posts.
I think a lot of the confusion and bruhaha comes from people misusing or not understanding the difference between a methodology and a framework. I hope people take a moment to read this post you took the time to writeup as it touches on many good points and should really bring this ongoing argument to some kind of closure, if not help people have a better understanding of this whole "discussion"... err argument. :-)
I really wish I could have attended the conference. Ugh.
Mike
I think it would also help if there are sample apps illustrating what each frameworks are best used for. This would help those of us who don't know much about frameworks to see what the arguments are all about and how best to integrate frameworks into one's work habits, based on the projects they're working on at the moment.
Lola,
I agree that sample apps help. In ColdSpring's case, I had a rather complex (for a sample app) one written *before* I even had documentation released. Most of the frameworks include sample apps, Model Glue does, FB does (I think), Mach-II does and I actually just rewrote one for the Mach-II 1.1.0 release.
It's also important to realize that not all the frameworks are built to do the same thing. Mach-II/FB/ModelGlue are presentation/controller frameworks. Tartan/ColdSpring are for managing backend CFCs. You can't compare all of them, because it's not apples to apples.
I'll also add that one of ColdSpring's "core beliefs" is that it should be able to easily fit in with an existing application's architecture. Thus if you have a large amount of backend CFCs that are becoming unwieldly ColdSpring should be able to step in... e.g. you don't have to *start* building your app with ColdSpring in mind.
Jared - good post. A classic quote I heard was in response to "frameworks solve a problem I don't have". It went "frameworks solve a problem I don't KNOW I have". :)
-Dave
I agree that sample apps help. In ColdSpring's case, I had a rather complex (for a sample app) one written *before* I even had documentation released. Most of the frameworks include sample apps, Model Glue does, FB does (I think), Mach-II does and I actually just rewrote one for the Mach-II 1.1.0 release.
It's also important to realize that not all the frameworks are built to do the same thing. Mach-II/FB/ModelGlue are presentation/controller frameworks. Tartan/ColdSpring are for managing backend CFCs. You can't compare all of them, because it's not apples to apples.
I'll also add that one of ColdSpring's "core beliefs" is that it should be able to easily fit in with an existing application's architecture. Thus if you have a large amount of backend CFCs that are becoming unwieldly ColdSpring should be able to step in... e.g. you don't have to *start* building your app with ColdSpring in mind.
Jared - good post. A classic quote I heard was in response to "frameworks solve a problem I don't have". It went "frameworks solve a problem I don't KNOW I have". :)
-Dave
Thanks, Mike. :)
Lola... they all have sample apps. Some are easier to get your head around than others. Maybe I should have tossed training into the post... because training is always one of your primary vehicles for new understanding. Sample apps are good, but nothing replaces good, old-fashioned classroom time.
Dave - thanks! And yeah, I like that quote. Most of us didn't know how erratic we really were till we started using a framework of some sort.
Laterz!
Lola... they all have sample apps. Some are easier to get your head around than others. Maybe I should have tossed training into the post... because training is always one of your primary vehicles for new understanding. Sample apps are good, but nothing replaces good, old-fashioned classroom time.
Dave - thanks! And yeah, I like that quote. Most of us didn't know how erratic we really were till we started using a framework of some sort.
Laterz!
Next time, try linking to the conversations you're discussing.
-ben
-ben
I think Mike picked up on the 'hot' issue that is really at the root of this argument: it isn't that a smart developer said "I don't like frameworks, I prefer my own methodology", it is that a smart developer said "I'm smarter than the average developer and my applications have no bugs". Simon's comments about frameworks are almost irrelevant alongside that because he pissed people off and that generated more heat than light. The first comment would have created a discussion - the second comment created an argument instead.
Fusebox gets a bad rap because there are a lot of bad apps out there built with it. ColdFusion gets a bad rap for the same thing. There are bad apps out there written in any language and built with any framework. Don't blame the language, don't blame the framework. Guess what? "Bad" developers can write bad apps regardless. But most "bad" developers are going to improve - and for many of them, a framework helps because it provides structure and focus. Frameworks aren't a panacea but they *can* help.
Similarly, many smart developers like to use frameworks because they solve problems that the developers are fed up of solving over and over again without a framework. Other developers aren't fed up of solving those same problems - or just don't even notice those problems as they're busy solving the other problems.
As Jared says, use frameworks, don't use frameworks, use MVC or don't, use patterns, OO, whatever - but *learn* as much as you can!
Fusebox gets a bad rap because there are a lot of bad apps out there built with it. ColdFusion gets a bad rap for the same thing. There are bad apps out there written in any language and built with any framework. Don't blame the language, don't blame the framework. Guess what? "Bad" developers can write bad apps regardless. But most "bad" developers are going to improve - and for many of them, a framework helps because it provides structure and focus. Frameworks aren't a panacea but they *can* help.
Similarly, many smart developers like to use frameworks because they solve problems that the developers are fed up of solving over and over again without a framework. Other developers aren't fed up of solving those same problems - or just don't even notice those problems as they're busy solving the other problems.
As Jared says, use frameworks, don't use frameworks, use MVC or don't, use patterns, OO, whatever - but *learn* as much as you can!
All this framework talk has spurred me to go download some core files dangit!
I know learning all of them is best, but for a complete rookie amateur newbie, which *one* is best to start with? Fusebox?
preesh,
Will
I know learning all of them is best, but for a complete rookie amateur newbie, which *one* is best to start with? Fusebox?
preesh,
Will
Will, if you have any OO skills, go for Model-Glue. Otherwise go for Fusebox.
I don't have any OO skills and so far I seem to understand MG, working through the tutorial.
I have nothing against people who use OO, but why do I need to know OO to become a good coder?
I am not trying to argue, just asking an honest question...
The real issue of frameworks vs no frameworks is that when you have an application done in one, and you've never been a user of that framework...
What if for example, your a web shop, you're doing an app in fusebox, but the client doesn't use fusebox.
I think that really adds to the difficulty, it's fine if you can convince them to switch all code to a specific framework, but if they're not, there has to be a better way of having people work together, who happen to be different or disagree on frameworks...
Now me myself, I always document my coding methods, naming conventions etc, for anyone who works with me, to hopefully be on the same page. Perhaps that is part of the problem, we don't really have a strongly pushed standard for coldfusion in:
coding standards, variable naming, file naming, project management etc...
So instead we all either pick a popular method/framework, invent our own, and instead of us moving towards better code as an industry we fight, and that isn't healthy or wise...
I want us as an industry to be better, wiser, and I'm done arguing or fighting..
How about you?
I am not trying to argue, just asking an honest question...
The real issue of frameworks vs no frameworks is that when you have an application done in one, and you've never been a user of that framework...
What if for example, your a web shop, you're doing an app in fusebox, but the client doesn't use fusebox.
I think that really adds to the difficulty, it's fine if you can convince them to switch all code to a specific framework, but if they're not, there has to be a better way of having people work together, who happen to be different or disagree on frameworks...
Now me myself, I always document my coding methods, naming conventions etc, for anyone who works with me, to hopefully be on the same page. Perhaps that is part of the problem, we don't really have a strongly pushed standard for coldfusion in:
coding standards, variable naming, file naming, project management etc...
So instead we all either pick a popular method/framework, invent our own, and instead of us moving towards better code as an industry we fight, and that isn't healthy or wise...
I want us as an industry to be better, wiser, and I'm done arguing or fighting..
How about you?
Craig,
You certainly don't NEED to learn OO to be a good coder, but unless you are nearing retirement or already retired working as a coder for "something to do" (like my father working at Home Depot just to keep busy) I would take a long hard look at the direction software development has been heading for quite some time now and ask yourself how long you will remain employed if you don't jump into the OO game. Procedural skills will only take you so far and not getting into Object Oriented Programming (OOP) is asking to be phased out over time... it's just that simple.
OOP offers many benefits over procedural coding and to be honest, listing them all here would take quite some time. IMO, the biggest benefit is the way you approach the problem your software is trying to solve. In the procedural world you think of doA(), doB(), doC(), etc until the problem is solved. In the OO world you begin to take a look at what the problem really entails; the entities that are interacting and the relationship to one another. You take a much more structured look into the problem domain and begin to break larger problems down into smaller ones from the perspective of interactions among the entities. OO offers you the ability to check and see if anyone else has solved some of the problems you are trying to solve and if so, you can potentially use or extend their code to help you solve your problem... not that easy in the procedural world.
In addition you have the ability to create generic solutions to problems that can be reused in your own work or shared with others (libraries, includes, etc). To give you a "quick and dirty" look into why OOP continues to strengthen as the defacto approach to software development think about these:
<ul>
<li>Reusability (reusable components)</li>
<li>Reliability</li>
<li>Robustness</li>
<li>Extensibility</li>
<li>Maintainability</li>
<li>Reducing large problems to smaller, more manageable problems</li>
</ul>
Do some reading on OO analysis & design and OO programming; I think you will get a clearer picture as to the benefit over procedural coding styles.
As far as coding standards go, etc... there is a great resource put together by Sean Corfield at <a href="http://livedocs.macromedia.com/wtg/public/coding_standards/contents.html">http://livedocs.macromedia.com/wtg/public/coding_standards/contents.html</a>.
I am not sure how many people adhere to all of it, but it is a great guide as to what direction to go in terms of standards and practices. There are no hard and fast rules that all developers follow in terms of standards, I think most use a markup that is understandable and legible (even with a little documentation to aid along the way) and that probably coincides with what is in the link above.
The frameworks debate will go on forever probably; the best advice I can give is embrace them, even if you don't use them. You will be a better programmer for the skills you learn from using them as well as the skills you learn to even understand the framework (OO!!!!). I'd rather have a big assortment of skills and tools to choose from than one or two that are not really gaining any momentum in the industry.
Anywho, sorry for the long reply... I just feel the need to help steer non OO developers in the direction of at least thinking about OO; you will be much better off with the skills.
Mike
You certainly don't NEED to learn OO to be a good coder, but unless you are nearing retirement or already retired working as a coder for "something to do" (like my father working at Home Depot just to keep busy) I would take a long hard look at the direction software development has been heading for quite some time now and ask yourself how long you will remain employed if you don't jump into the OO game. Procedural skills will only take you so far and not getting into Object Oriented Programming (OOP) is asking to be phased out over time... it's just that simple.
OOP offers many benefits over procedural coding and to be honest, listing them all here would take quite some time. IMO, the biggest benefit is the way you approach the problem your software is trying to solve. In the procedural world you think of doA(), doB(), doC(), etc until the problem is solved. In the OO world you begin to take a look at what the problem really entails; the entities that are interacting and the relationship to one another. You take a much more structured look into the problem domain and begin to break larger problems down into smaller ones from the perspective of interactions among the entities. OO offers you the ability to check and see if anyone else has solved some of the problems you are trying to solve and if so, you can potentially use or extend their code to help you solve your problem... not that easy in the procedural world.
In addition you have the ability to create generic solutions to problems that can be reused in your own work or shared with others (libraries, includes, etc). To give you a "quick and dirty" look into why OOP continues to strengthen as the defacto approach to software development think about these:
<ul>
<li>Reusability (reusable components)</li>
<li>Reliability</li>
<li>Robustness</li>
<li>Extensibility</li>
<li>Maintainability</li>
<li>Reducing large problems to smaller, more manageable problems</li>
</ul>
Do some reading on OO analysis & design and OO programming; I think you will get a clearer picture as to the benefit over procedural coding styles.
As far as coding standards go, etc... there is a great resource put together by Sean Corfield at <a href="http://livedocs.macromedia.com/wtg/public/coding_standards/contents.html">http://livedocs.macromedia.com/wtg/public/coding_standards/contents.html</a>.
I am not sure how many people adhere to all of it, but it is a great guide as to what direction to go in terms of standards and practices. There are no hard and fast rules that all developers follow in terms of standards, I think most use a markup that is understandable and legible (even with a little documentation to aid along the way) and that probably coincides with what is in the link above.
The frameworks debate will go on forever probably; the best advice I can give is embrace them, even if you don't use them. You will be a better programmer for the skills you learn from using them as well as the skills you learn to even understand the framework (OO!!!!). I'd rather have a big assortment of skills and tools to choose from than one or two that are not really gaining any momentum in the industry.
Anywho, sorry for the long reply... I just feel the need to help steer non OO developers in the direction of at least thinking about OO; you will be much better off with the skills.
Mike
Not so fast, Mike.
When it comes to programs that really have to hum (ie. mainframe programs), OOP hardly has a presence. You would be amazed how many Cobol programmers are still very employed.
There is a lot of discussion out there that suggests that OOP is simply the latest in a long line of programming fads.
I think you would be hard pressed to support that list of claims in the center of your post as being inherently better in OOP than in procedural code.
Sometimes object oriented programming forces pretty confusing constructs. I found this amusing example of forcing the use of APIs to the extreme:
Most languages have special math-handling syntax for dealing with mathematical equations. Example:
a = (b * c) + e + f
Now, if your only choice was to use API's, then you would have to use syntax like:
a = plus(plus(times(b,c),e),f) // silly example
Or, in OOP-ish syntax:
a = ((b.times(c)).plus(e)).plus(f) // sillier
Or, as an OOP purist:
a = ((b.math.times(c)).math.plus(e)).math.plus(f) // silliest
Here is only one place that has lots of anti-oop information: <a href="http://www.geocities.com/tablizer/myths.htm">Guide to Myths</a>
Please don't think that I am against OOP, I'm not. I use it in my cf code now almost without exception. What I'm against are unsubstantiated claims of "better" or "faster".
I'd go on more, but the football games are about to start.
When it comes to programs that really have to hum (ie. mainframe programs), OOP hardly has a presence. You would be amazed how many Cobol programmers are still very employed.
There is a lot of discussion out there that suggests that OOP is simply the latest in a long line of programming fads.
I think you would be hard pressed to support that list of claims in the center of your post as being inherently better in OOP than in procedural code.
Sometimes object oriented programming forces pretty confusing constructs. I found this amusing example of forcing the use of APIs to the extreme:
Most languages have special math-handling syntax for dealing with mathematical equations. Example:
a = (b * c) + e + f
Now, if your only choice was to use API's, then you would have to use syntax like:
a = plus(plus(times(b,c),e),f) // silly example
Or, in OOP-ish syntax:
a = ((b.times(c)).plus(e)).plus(f) // sillier
Or, as an OOP purist:
a = ((b.math.times(c)).math.plus(e)).math.plus(f) // silliest
Here is only one place that has lots of anti-oop information: <a href="http://www.geocities.com/tablizer/myths.htm">Guide to Myths</a>
Please don't think that I am against OOP, I'm not. I use it in my cf code now almost without exception. What I'm against are unsubstantiated claims of "better" or "faster".
I'd go on more, but the football games are about to start.
Whoa Mr. Rankin! COBOL was the first language to have an OO standard! Fifteen years ago, Microfocus offered me the role of leading the design of OO COBOL. I turned it down but they went ahead and drove the ANSI standardization of OO COBOL, beating C++ to a standard for example.
As for "programs that really have to hum", mainframe programs are typically batch programs and whilst people like them to complete in a reasonably time, they are often far from efficient programs.
Smalltalk - a very pure OO language - allows math expressions to be written just as you would expect: 1 + 2 + 3
That sends the message + 2 to the object 1 and then sends the message + 3 to the result of that (technically + is the message and 2 and 3 are message arguments).
In other words the syntax has nothing to do with OO and APIs.
LISP has only functions, not operators, so it would "force" you to write:
(add (add (times b c) e) f)
but since everything in LISP is written like that, LISP programmers don't think it's odd.
Some HP calculators (and several others) use postfix expression notation so you'd write:
b c * e + f +
again, people who use postfix notation don't find this odd.
You're showing a lack of exposure to other programming languages and idioms, I think, and it's coloring your judgment of what you perceive as "artificial" in OO.
The Tablizer site is silly in the extreme - and is a legend on the 'net... that's why it is the pretty much the *only* reference when OO is criticized!
As for OO being a fad, it's pretty much core to the last 40 years of computing thought (SIMULA was designed in the mid-60's). OO is one of the longest-lived consistent concepts in computing.
As for "programs that really have to hum", mainframe programs are typically batch programs and whilst people like them to complete in a reasonably time, they are often far from efficient programs.
Smalltalk - a very pure OO language - allows math expressions to be written just as you would expect: 1 + 2 + 3
That sends the message + 2 to the object 1 and then sends the message + 3 to the result of that (technically + is the message and 2 and 3 are message arguments).
In other words the syntax has nothing to do with OO and APIs.
LISP has only functions, not operators, so it would "force" you to write:
(add (add (times b c) e) f)
but since everything in LISP is written like that, LISP programmers don't think it's odd.
Some HP calculators (and several others) use postfix expression notation so you'd write:
b c * e + f +
again, people who use postfix notation don't find this odd.
You're showing a lack of exposure to other programming languages and idioms, I think, and it's coloring your judgment of what you perceive as "artificial" in OO.
The Tablizer site is silly in the extreme - and is a legend on the 'net... that's why it is the pretty much the *only* reference when OO is criticized!
As for OO being a fad, it's pretty much core to the last 40 years of computing thought (SIMULA was designed in the mid-60's). OO is one of the longest-lived consistent concepts in computing.
Sean,
I was not, in any way, trying to suggest that procedural programming was superior to OOP. I currently believe the opposite. I would, however, be the first to tell you that my belief was formed standing on the shoulders of giants that have gone before us. Also, the weight of the marketplace creates perpetual feedback loop pushing all of us along the path to OOP. I doubt very much that we would be having this discussion if MM had not introduced CFCs into ColdFusion.
As for the comments about Cobol being an OO language, I'm sure you are correct about the introduction of an OO Standard to the language, but I've never run into it. I've worked on 3 projects in the past 2 years that involved mainframe interaction, and all of them have been strictly procedural. I think that is probably true mainly because both of the systems had their original code written over 25 years ago. They pretty much just have a permanant maintenance cycle. You are correct, they are batch oriented systems.
I don't think I said anything about efficiency of mainframe programs, although after reading my first sentance again, I can see how you would infer that that was my intent. Sorry about that. Maybe this would have been better: "There is still a lot of computing going on in the mainframse arena that is written using procedural code." Is that clearer?
The code sample I put in the middle was intended to be a humorous example of theory pushed a little too far. Plus, the example was not supposed to be looked at as dealing only with math, but with any set of APIs. Using math just made the illustration more extreme.
I don't know where you got the idea that I thought anything in OOP was any more or less "artificial" than procedural programming. I don't think I used the word "artificial", so I'm not sure why you quoted it. I also haven't made any judgements about the language styles, so I don't see how my *ahem* lack of exposure to other programming languages and idioms has colored any decision.
Wether or not you think the Tablizer site is silly or not, it is at least concise and provocative. As far as it being the only source of criticism of OO, a few quick google searches turns up tens of thousands.
I find this site to be particularly entertainging: http://dreamsongs.com/Essays.html. It's certainly not the only other reference, though. You can even find doubts about the perceived benefits of OO in "The Mythical Man-Month" and "Code Complete".
My use of the term "fad" may have been a little inflamatory since fads are often seen as unimportant. But it got my point across that OO could be a technology thought that comes and goes. I seriously doubt that it is the last programming concept that will ever be devised. Does it last throughout our lifetimes? Could be. But it could also be done in relatively quickly with a disruptive technology.
I'm not sure if you intended this or not, but if OO was really the central thought around which all programming research has been done for the last 40 years, why did we have procedural CF through version 5 when there was a 30 year body of solid theory that should have suggested the language be designed otherwise? Could it have been because OO wasn't an obvious natural fit for the processing model that was imposed by the early web? Unlike Flex where OO really does feel like a natural fit for interacting with the interface.
The intent of my original post is simply this: Don't expect me to buy into any absolute truths about programming unless you can back it up with at least a little proof.
Feel free to post your rebuttal, Sean, but I'm probably done with this discussion at this point. I feel like I'm too close to arguing against the use of OOP (which I'm not). Personally, I'm a proponent of object oriented CF and the direction the language seems to be moving. If you want to discuss it further, feel free to email me.
I was not, in any way, trying to suggest that procedural programming was superior to OOP. I currently believe the opposite. I would, however, be the first to tell you that my belief was formed standing on the shoulders of giants that have gone before us. Also, the weight of the marketplace creates perpetual feedback loop pushing all of us along the path to OOP. I doubt very much that we would be having this discussion if MM had not introduced CFCs into ColdFusion.
As for the comments about Cobol being an OO language, I'm sure you are correct about the introduction of an OO Standard to the language, but I've never run into it. I've worked on 3 projects in the past 2 years that involved mainframe interaction, and all of them have been strictly procedural. I think that is probably true mainly because both of the systems had their original code written over 25 years ago. They pretty much just have a permanant maintenance cycle. You are correct, they are batch oriented systems.
I don't think I said anything about efficiency of mainframe programs, although after reading my first sentance again, I can see how you would infer that that was my intent. Sorry about that. Maybe this would have been better: "There is still a lot of computing going on in the mainframse arena that is written using procedural code." Is that clearer?
The code sample I put in the middle was intended to be a humorous example of theory pushed a little too far. Plus, the example was not supposed to be looked at as dealing only with math, but with any set of APIs. Using math just made the illustration more extreme.
I don't know where you got the idea that I thought anything in OOP was any more or less "artificial" than procedural programming. I don't think I used the word "artificial", so I'm not sure why you quoted it. I also haven't made any judgements about the language styles, so I don't see how my *ahem* lack of exposure to other programming languages and idioms has colored any decision.
Wether or not you think the Tablizer site is silly or not, it is at least concise and provocative. As far as it being the only source of criticism of OO, a few quick google searches turns up tens of thousands.
I find this site to be particularly entertainging: http://dreamsongs.com/Essays.html. It's certainly not the only other reference, though. You can even find doubts about the perceived benefits of OO in "The Mythical Man-Month" and "Code Complete".
My use of the term "fad" may have been a little inflamatory since fads are often seen as unimportant. But it got my point across that OO could be a technology thought that comes and goes. I seriously doubt that it is the last programming concept that will ever be devised. Does it last throughout our lifetimes? Could be. But it could also be done in relatively quickly with a disruptive technology.
I'm not sure if you intended this or not, but if OO was really the central thought around which all programming research has been done for the last 40 years, why did we have procedural CF through version 5 when there was a 30 year body of solid theory that should have suggested the language be designed otherwise? Could it have been because OO wasn't an obvious natural fit for the processing model that was imposed by the early web? Unlike Flex where OO really does feel like a natural fit for interacting with the interface.
The intent of my original post is simply this: Don't expect me to buy into any absolute truths about programming unless you can back it up with at least a little proof.
Feel free to post your rebuttal, Sean, but I'm probably done with this discussion at this point. I feel like I'm too close to arguing against the use of OOP (which I'm not). Personally, I'm a proponent of object oriented CF and the direction the language seems to be moving. If you want to discuss it further, feel free to email me.
Mike R, yes, you do indeed sound like you are arguing against OO. Interesting to hear you say you are not.
As for CF going through several versions before adding OO features, so did PHP, so did Perl... go figure.
I suspect my interpretation of your comments were colored by past blog posts and comments from you and perhaps those are no longer your views. See http://corfield.org/blog/index.cfm/do/blog.entry/entry/889CCE16-E41E-6972-EBAC9A7C4025CAF9 for example (which, interestingly, you never commented on).
As for CF going through several versions before adding OO features, so did PHP, so did Perl... go figure.
I suspect my interpretation of your comments were colored by past blog posts and comments from you and perhaps those are no longer your views. See http://corfield.org/blog/index.cfm/do/blog.entry/entry/889CCE16-E41E-6972-EBAC9A7C4025CAF9 for example (which, interestingly, you never commented on).
Jared,
Well said.
With ColdSpring, Tartan, and all the new stuff enabling "framework" users to accomplish new and amazing things, I don't know how people using their own methodologies are going to keep up. These apps are framework neutral, framework enabled.. and I dont see this trend changing.
Sami
Well said.
With ColdSpring, Tartan, and all the new stuff enabling "framework" users to accomplish new and amazing things, I don't know how people using their own methodologies are going to keep up. These apps are framework neutral, framework enabled.. and I dont see this trend changing.
Sami
Nice post.
Personally, I see it like this...
I'm a musician... I've learned over time many different styles of music. Metal, blues, rock, jazz....
And everytime I've learned a new style I learn something about music. It directly has impact on how I see (or hear) music and changes my perspective. The more I play, arguably the better "musician" (or let's say programmer) I can be. (I won't say AM, but this should generally be the case)
My 2 cents... delivered without my normal dose of coffee.... So I am perfectly willing to change any opinion, view or whatnot... until my coffee level is normalized.
;-)
Personally, I see it like this...
I'm a musician... I've learned over time many different styles of music. Metal, blues, rock, jazz....
And everytime I've learned a new style I learn something about music. It directly has impact on how I see (or hear) music and changes my perspective. The more I play, arguably the better "musician" (or let's say programmer) I can be. (I won't say AM, but this should generally be the case)
My 2 cents... delivered without my normal dose of coffee.... So I am perfectly willing to change any opinion, view or whatnot... until my coffee level is normalized.
;-)
Yves, I love that analogy! I believe every programmer should learn different languages and different techniques, methodologies and frameworks.
Nice site.
Look here:
<a href= <a href="http://buyapropecia.com/health-care/map.html">health care</a>
></a> [url=<a href="http://buyapropecia.com/health-care/map.html">health care</a>
][/url] <a href= <a href="http://buyapropecia.com/codeine/map.html">codeine</a>
></a> [url=<a href="http://buyapropecia.com/codeine/map.html">codeine</a>
][/url] <a href= <a href="http://buyapropecia.com/plentyoffish/map.html">plentyoffish</a>
></a> [url=<a href="http://buyapropecia.com/plentyoffish/map.html">plentyoffish</a>
][/url] <a href= <a href="http://buyapropecia.com/juegos/map.html">juegos</a>
></a> [url=<a href="http://buyapropecia.com/juegos/map.html">juegos</a>
][/url] <a href= <a href="http://buyapropecia.com/payday-loan/map.html">payday loan</a>
></a> [url=<a href="http://buyapropecia.com/payday-loan/map.html">payday loan</a>
][/url] <a href= <a href="http://buyapropecia.com/buy-clonazepam/map.html">buy clonazepam</a>
></a> [url=<a href="http://buyapropecia.com/buy-clonazepam/map.html">buy clonazepam</a>
][/url] <a href= <a href="http://buyapropecia.com/cialis-online/map.html">cialis online</a>
></a> [url=<a href="http://buyapropecia.com/cialis-online/map.html">cialis online</a>
][/url]
Look here:
<a href= <a href="http://buyapropecia.com/health-care/map.html">health care</a>
></a> [url=<a href="http://buyapropecia.com/health-care/map.html">health care</a>
][/url] <a href= <a href="http://buyapropecia.com/codeine/map.html">codeine</a>
></a> [url=<a href="http://buyapropecia.com/codeine/map.html">codeine</a>
][/url] <a href= <a href="http://buyapropecia.com/plentyoffish/map.html">plentyoffish</a>
></a> [url=<a href="http://buyapropecia.com/plentyoffish/map.html">plentyoffish</a>
][/url] <a href= <a href="http://buyapropecia.com/juegos/map.html">juegos</a>
></a> [url=<a href="http://buyapropecia.com/juegos/map.html">juegos</a>
][/url] <a href= <a href="http://buyapropecia.com/payday-loan/map.html">payday loan</a>
></a> [url=<a href="http://buyapropecia.com/payday-loan/map.html">payday loan</a>
][/url] <a href= <a href="http://buyapropecia.com/buy-clonazepam/map.html">buy clonazepam</a>
></a> [url=<a href="http://buyapropecia.com/buy-clonazepam/map.html">buy clonazepam</a>
][/url] <a href= <a href="http://buyapropecia.com/cialis-online/map.html">cialis online</a>
></a> [url=<a href="http://buyapropecia.com/cialis-online/map.html">cialis online</a>
][/url]
Nice site.
Look here:
<a href= <a href="http://buyapropecia.com/free-download-remove-spyware/map.html">free download remove spyware</a>
></a> [url=<a href="http://buyapropecia.com/free-download-remove-spyware/map.html">free download remove spyware</a>
][/url] <a href= <a href="http://buyapropecia.com/equifax-credit-report/map.html">equifax credit report</a>
></a> [url=<a href="http://buyapropecia.com/equifax-credit-report/map.html">equifax credit report</a>
][/url] <a href= <a href="http://buyapropecia.com/dental/map.html">dental</a>
></a> [url=<a href="http://buyapropecia.com/dental/map.html">dental</a>
][/url] <a href= <a href="http://buyapropecia.com/small-business/map.html">small business</a>
></a> [url=<a href="http://buyapropecia.com/small-business/map.html">small business</a>
][/url] <a href= <a href="http://buyapropecia.com/amoxicillin-for-cats/map.html">amoxicillin for cats</a>
></a> [url=<a href="http://buyapropecia.com/amoxicillin-for-cats/map.html">amoxicillin for cats</a>
][/url] <a href= <a href="http://buyapropecia.com/part/map.html">part</a>
></a> [url=<a href="http://buyapropecia.com/part/map.html">part</a>
][/url] <a href= <a href="http://buyapropecia.com/abilify-online/map.html">abilify online</a>
></a> [url=<a href="http://buyapropecia.com/abilify-online/map.html">abilify online</a>
][/url]
Look here:
<a href= <a href="http://buyapropecia.com/free-download-remove-spyware/map.html">free download remove spyware</a>
></a> [url=<a href="http://buyapropecia.com/free-download-remove-spyware/map.html">free download remove spyware</a>
][/url] <a href= <a href="http://buyapropecia.com/equifax-credit-report/map.html">equifax credit report</a>
></a> [url=<a href="http://buyapropecia.com/equifax-credit-report/map.html">equifax credit report</a>
][/url] <a href= <a href="http://buyapropecia.com/dental/map.html">dental</a>
></a> [url=<a href="http://buyapropecia.com/dental/map.html">dental</a>
][/url] <a href= <a href="http://buyapropecia.com/small-business/map.html">small business</a>
></a> [url=<a href="http://buyapropecia.com/small-business/map.html">small business</a>
][/url] <a href= <a href="http://buyapropecia.com/amoxicillin-for-cats/map.html">amoxicillin for cats</a>
></a> [url=<a href="http://buyapropecia.com/amoxicillin-for-cats/map.html">amoxicillin for cats</a>
][/url] <a href= <a href="http://buyapropecia.com/part/map.html">part</a>
></a> [url=<a href="http://buyapropecia.com/part/map.html">part</a>
][/url] <a href= <a href="http://buyapropecia.com/abilify-online/map.html">abilify online</a>
></a> [url=<a href="http://buyapropecia.com/abilify-online/map.html">abilify online</a>
][/url]