Hal Helms has written an article entitled A New Vision for ColdFusion. For the most part, I agree with everything Hal says, although I don’t really see this as a new vision, as much as being true to the original vision and intent. This one is recommend reading.
Hal Helms On ColdFusion Futures And Direction
19 responses to “Hal Helms On ColdFusion Futures And Direction”
-
SPOT ON! Go Hal!
-
Ben,
You should show this article to your powers that be and tell them to take it to heart. Hal hit the nail on the head with this one.
If you think about it, almost every language out there is moving to creating interfaces with AJAX faster than CF. Personally I think that CF is way behind in this effort and I’m amazed that Adobe hasn’t seen this.
A great example of this is Atlas (Ajax.Net). Being able to wrap Atlas controls around existing code like Datagrids and them becoming automagically Ajaxed is amazing. We seem the same concepts going on with Ruby on Rails, CakePHP, Django and many other frameworks that are making creating interfaces a lot easier.
Maybe it is time to step back and rethink where CF is heading. Maybe Adobe is put some money behind some of the open source frameworks and projects out there to bolster CF’s presence. -
Tony, I basically agree with you, but I am less hung up on Ajax. This is not about Ajax at all, it is about the presentation tier, and Ajax is just one part of that (albeit the most hyped part, right now). And there is not a whole lot of disagreement actually amongst the CF team, if you look at CFMX7 a big chunk of what we did with that release was just that, presentation. Be it forms, printing, reporting, or whatever. Now you are free to debate what we did and how well we did it, but you have to admit that the presentation tier is indeed a big chunk of what we invested in. And we’re doing the same for Scorpio, too.
— Ben -
GREAT article. I see more and more interest in "Agile" development methodologies, from large corporations (Gartner, in particular, is writing alot of reseach papers regarding this, to educate their customers). Positioning CF for this market would be ideal.
Ben, you’ve probably heard this before (maybe even from me) – but it’s high time Adobe aimed some marketing of CF at the CIO level. Break down perceptions, and brand yourself, before competitors to it for you. Get the good name of CF out there, so that it’s not alien when a CIO hears it mentioned in a meeting.
Cheers,
David -
While I agree that CF’s forte is speed, and that the presentation and UI-side need beefing up, is there really any reason we can’t have interfaces and constructors and so on as well for us folk doing the backend? Does one have to preclude the other?
And if we do want to concentrate on front ends, how about working on all of the issues involved with attempting to do modern (non-flash) forms processing and error handling? -
I’ve said before my one wish for CF8 is a struct literal (me = {firstname: ‘patrick’, lastname: ‘mcelhaney’}). From there it’s probably not far to native JSON support, which would be awesome for AJAX.
Come to think of it, I would love to be able to use Actionscript in CFScript. -
David, it’s interesting that you bring up "agile" methodologies. In 2000, they were called "lightweight" methodologies. When a bunch of "lightweight" methdologists go together for a "lightweight" conference, one of the first things they did was agree that the word "lightweight" had to go. They agreed on "agile" as a much more flattering alternative.
http://www.agilemanifesto.org/history.html -
Patrick: You do know there are JSON encode/decode udf’s out there, don’t you?
-
I’ve looked at interfaces in java. I’ve thought about their use in CF. I’ve even looked over all of the BlueDragon interface docs (which are actually really sweet) and I can say flat out that I don’t see a need for them. All an interface is is another validation layer.
"you must have these methods in your CFC" is all it says.
I’d say we need static access to methods first. I’d say that we need abstract methods next. I think we need a real education for 99% of the CF community as to what and when to use inheritance.
And as for constructors, the community ‘standard’ looks good enough to me. -
Just to play the devil’s advocate:
Isn’t presentation theoritically being solved by solutions such as JSF and other frameworks for J2EE? Isn’t it a bit more of a struggle to integrate CF as a front end for J2EE than it would be to leverage frameworks and solutions already being pursued, adopted and championed by the J2EE community, wherein there is a higher level of tool support for example? -
No, interfaces are (or at least can be) more than just a "validation" layer. But I agree that not having "class" (static) methods is another biggie.
And as long as we’re talking about Blue Dragon, "threading" also has a lot of potential for doing logging and other out-of-the-response-stream transactions.
But again, these are all "back-end" enhancements, and things that, apparently, Hal doesn’t think we need. -
And I agree with him.
Ben and I once had a mock fist fight over the CFINSERT tag. I felt it was terrible and should never be used and he disagreed. On the whole, he was right. It has its place and for many who use the ColdFusion without being big in SQL, it works perfectly. Yes, they should know SQL, but if they don’t….
Why should Adobe put a function into ColdFusion that will be used by less than .001% of their programmers? Because it sounds good? Because it has buzz? That results in Corba being included and rarely used.
Lets educate people on UDFs and CFCs first. On OOP next. On proper code writing (such as Ben’s next blog post). Interfaces are just going to confuse most people who not only don’t see a reason for them, but can’t.
Now if you say interfaces are more than just a validation layer, please tell me how. The whole ‘inheritence without multiple inheritence’ is a lie as there is no code to inherit, only rules. Makes me not care about using them right there. -
I could not agree with Hal more, and usually I disagree when it comes to complex ideas (probably because I can’t wrap my head around them!)
I am not necessarily a programmer. I wouldn’t consider myself a real DBA. I am a modest Sysadmin. I have decent security skills. I am a generalist. I *am* a 8-year hard-core CFML fan. ColdFusion is my rock star. I whip out web applications fleet-footedly that leaves most people in awe.
UI? Make the best and users love you.
Speed? Make it fast and managers love you.
Frameworks? Make it well and it will last.
AJAX? Don’t care.
Java? Don’t care.
Flex? Don’t care.
Flash? Don’t care.
Functions? Don’t care.
Interfaces? Don’t care.
Static access to methods? Bah! My head explodes.
I say this not to poke fun at anyone — somebody has to be serious about all this stuff after all. But I don’t care about the underpinnings of what makes it work necessarily and I think a lot of CF coders are the same way. I want to know how cool I can make it look, how quickly I can make it and how easy it is going to be to learn it. If it takes a week to grasp a concept, chances are I ain’t gonna do it — there is more important stuff to do. I think we get too wrapped-up in this sometimes, and to me Hal’s interpretation is just incredible — could not be more spot on. We mustn’t forget the real roots of ColdFusion — even if it is K.I.S.S.
And simplicity is the guiding light for most users on the planet. We forget that. Often. We’re not normal users. Anything that makes us look this good, this fast and makes users happy has got to embrace that very fact. THAT sells. If ColdFusion looses its way in a sea of uncertainty all the C-level execs arent’ gonna listen to us, even if they see what we do and experience the results. Herd mentaility indeed! ("nobody gets fired for choosing IBM")
Adobe, please don’t rain on my parade and call ColdFusion what it is not — I’m putting people to work and making their lives easier as quickly as possible, not learning the esoterics of programming languages.
Ahhhh, I feel better. Thanks Hal! -
Hal certainly struck a chord with me. We don’t build applications here, we prototype, and then we throw it away and do V2 and V3 and V4, with the users refining what they want as they learn what we and they can do. Theoreticaly our prototypes get handed over to our .net gurus to be fixed/industrialised. But our user requirements change so often the lifespan of any given version ranges form 6 to 18 months. So they never think its worthwhile to port one of our apps, they also hate all our clever UI tricks as they’re hard to do. We have systems where we’re on V8 and its been in place for 5 years.
We’re currently flooded with work where the requirements are at best vague and at worst non existent. We can knock something up in a few days and then sort out the backend once we’ve got the users happy with the up front stuff. Our formal development teams hate us with a passion as our apps are cheap, fast and fit for purpose. Not over engineered and very very flexible. The ability to respond to the way the business changes makes us the most useful dev team the business currently has. And they haven’t seen the Flex based stuff we have planned yet.
Our biggest problem is we have to grow all our own CF bodies. -
PS
If you can give me even half the Lifecycle functionality exposed through something like CF I’ll finally be able to tell opentext where to shove its Livelink product. -
Ben, I agree with you about CF’s original vision. But I felt that Macromedia’s marketing of CF missed the point. Instead of making the case head-on for a different kind of language, it too often spread a message that "CF is the fastest way to build Java apps" or "ColdFusion IS Java". That’s "me-too" marketing.
I responded to Vince Bonfanti’s blog post on this subject in which he defended BD’s inclusion of Java-like features to the language as "responding to customers’ requests" (and hence, good business) with this:
Creative works (and I include computer languages in this) need a creative vision in order to be compelling. However appealing the simplicity of "we just do what our customers tell us" may be, it fails in having anything original or thought-provoking to offer prospects. It offers nothing objectionable, but nothing original either. Personally, I prefer St. Augustine’s wise dictum: "Sin boldly." It’s not that an original vision is sure to win, but that an uninspired, copycat one is sure to fail.
The success of Ruby shows that there is a hunger for a language that deserts the feature wars for a compellingly different vision. I think the world is finally catching up with the vision the Allaire brothers initially held. I think it’s time to abandon the "we’re just as good as Java" mentality for a new one — one that inspires and enables creators, not just software engineers. -
Hal,
You raise a good point, there has been a lot of ‘CF IS Java’ positioning, and I’ve personally played a role in that positioning. Just to give you some perspective, a big part of that positioning is a defensive move against the ‘we are moving away from CF because we have a mandate to use Java now’ mentality. You’d not believe how often I hear that stupidty from CIOs, CTOs, and whichever exec happend to glance at a Gartner Magic Quadrant or read the tech page of WSJ. The reality is that the ‘CF IS Java’ story has been the only reason that CF is still used in some massive (and significantly revenue generating) deployments. Those execs, who have a bit of a ‘nobody got fired for buying in to J2EE’ mentality, need reassuring, and need to know that CF is not a threat to where they feel they need to be headed. Now, the ‘CF is Java’ story is not only a defensive story, but that is a big part of it. Of course, there is a risk too, as you noted.
— Ben -
I must say that the whole "ColdFusion is Java" argument really does help win over the uninitiated. When you talk in circles who want to know things like how garbage collections are handled, its nice to know that maintaining multiple instances of a J2EE platform helps the robustness and scalability of our platform. I think it is a big bonus when CF moved to this java architecture. And when technology decisions are often made by those who are not "server experts", it is helpful to promote the Java layer when their peers are talking about Java and .Net.
-
I agree wholeheartedly with Garrett Wiedmeier. As a former project manager for an enterprise application, there were many debates about what language and framework we should be using to develop our application. I had a choice between Java, C#, and ColdFusion, and to me the choice was a no brainer. ColdFusion allowed us to move our application forward faster than anyone would have imagined and our users were blown away with the user interface, especially with the interactive graphs with drilldown capability. In short, ColdFusion rocks even with it’s existing flaws.
I’m not sure if most people are aware of this but many companies are staffed by novice developers who don’t have the skills to harness the power of Java or C#. Many people who are developing applications in many of the companies in the US are new to web development and many never studied programming in a formal academic environment. ColdFusion is by far the best program for anyone who wants to develop really nice applications with little or no training, especially if they use CFWACK as a guide.
Companies are in the business to make money and keeping costs down means the potential for higher profits. If Adobe significantly changes the existing functionality in an attempt to appease to the "pure programming" community they are going to lose big time. Visual design with drag and drop components that take care of the back-end coding is the name of the game in today’s environment because speed in development is becoming more and more important as companies vie for market share. IT developers are business support, and if it takes the IT department longer to develop applications or if the applications they develop are harder to maintain and change, the company loses.
In my opinion, Adobe should continue to keep ColdFusion simple, easy, and fun, because the more difficult they make it, the less people will be inclined to use it.
Leave a Reply