34
Replies
But just to make two quick point about this dying technology, Adobe apparently sells more new CF licenses every quarter and there are now at least four CFML engines for this dying technology.
Ahh, something concrete I can throw out there, this is good. Hard facts is what I need for this, real stats! 
I found out what the individual who made this statement based it on. It's easy enough to shoot down the "saw/tried it many years ago", but his primary reasoning was an unscientific observation of the number (and type) of job offers being made by companies. He has perceived a slow decline in ColdFusion on the job market (but agrees this can't be taken a hard evidence of anything).
I got him to backtrack a little into saying that he'd favor simply creating standard Java libraries, project templates, or otherwise "standard" tools to do the work CF does for you. My counter was basically - why do all that when you have a well designed, mature, commercial tool out there which gives you these things for free?
He keeps going back to this "market share" argument where of course Java (meaning, Java w/o CF) rules, .NET takes second, and most everything else isn't worth serious consideration. Very frustrating.
I'm in the J2EE(/Flex) world myself but I feel like I'm much more open to trying something to speed up slow and fragile J2EE development. Basically a way to do "rapid application development" in Java is what I need to make Flex/Java development in my office competitive with a rather primitive (but very efficient) RAD tool being pushed hard by management. I've yet to dive into CF deeply, but I feel like CF is exactly what I'm looking for, especially with it's Flex integration.
In the end it doesn't matter (since I have the decision making power) if I can convince this coworker whether CF is worth considering (that's all I'm really saying, since I've yet to do more than some basic CF tutorials). But still, you want your team to agree on such things if at all possible. I've a lot of work to do!
Like I said ... ColdFusion works. In fact, the CFML approach is an extremely clever one ... and its implementation (here/s to you, Adobe, and/or to whomever you bought it from ...) is downright "shrewd." If you want to quickly implement a web-site or an application server that will handle a lot of users and that will "scale-up" without having to be reimplemented, you'd be hard pressed to find a better solution.
It isn't immediately obvious at first glance why this should be so. A ColdFusion page, after all, looks a whole lot like PHP or something similar. But here comes the great-big difference: how the CFML page is used by the ColdFusion engine. Also: ColdFusion is fundamentally designed to be an application server, not a web-page server.
A CFML page is, effectively, "an XML document." It does not use XML namespaces in the now-accepted way because (uhh...) it was invented and on-the-scene before that idea came about. But that's what it is, and it's used as an input to a just-in-time (JIT) compiler. The CFML code is an XML tree-structure which is (very quickly!) parsed and understood so that the JIT compiler can on-the-fly generate the appropriate code for fast execution.
The ColdFusion application server(s), far from being "a general provider of any ol' web-page," (is|are) keenly aware of what each page is doing. ColdFusion provide a wide variety of features ... threads, shared storage, load balancing, fulltext indexing, links to surrounding programming environments ... some of which are made available implicitly. That is to say, without demanding a substantial change to the application code.
The CFML text is, to some degree, declarative. It has a certain over-arching sense of "timing" which flows generally from the top of the source-file to the bottom, but a <cfinput> tag (for example) declares what behavior is desired at that point. The <cftransaction> tag stipulates that all of the code that it encloses should abide by certain characteristics at execution-time. There are many other examples. And what the ColdFusion system does with that information, at execution time, in order to accomplish the specified result, is not entirely spelled-out step-by-step in the CFML. It's determined on-the-fly, based not only on the source-code but also on the context.
That is "what all the fuss is about." You can deploy pages very quickly, into a very robust programming environment, and know that they will work on both a small internal site and a very large multi-server enterprise site, "right out of the box." As a tool to do what ColdFusion is designed to do, it is very hard to beat. There is a tremendous business need out there for "doing precisely what ColdFusion is designed to do." It might or might not be glamorous in the eyes of a fourteen year old , but it is crucial.
The graph displays the percentage of jobs search terms in the simplyhired.com job listing. Since August 2008, the following has occurred:
* Asp jobs increased 15%
* Jsp jobs increased 56%
* Php jobs increased 83%
* Ruby jobs increased 158%
* Python jobs increased 152%
* Coldfusion jobs increased 37%
(Courtesy of www.simplyhired.com)
Mark Twain: "The rumors of my death have been greatly exaggerated"
Well, the fact of the matter is that it takes fewer programmers to get the job done with ColdFusion, so it stands to reason that there are fewer jobs listed!
BKBK wrote:
tclaremont wrote:
Well, the fact of the matter is that it takes fewer programmers to get the job done with ColdFusion, so it stands to reason that there are fewer jobs listed!
Oh, I like that.
Indeed. Nice one.
--
Adam
Thank you for the clarification (regarding XML).
There are several aspects which these graphs do not consider:
- Where, and how, are the applications being deployed. ColdFusion makes certain tasks considerably easier, which therefore drives its adoption more strongly in some areas vs. others. The Wild and Wooly Web (WWW) is chock-full of "I wanna have a great big blog for my iddy-biddy business oops I'm broke! buh-bye!!" sites, and "let's do e-commerce to sell the bars of soap that I make as a hobby" sites. Anything can be used to do that.
- The entire concept of "legacy code." An application might be in-service for a very long time: originally built long ago, and evolving ever since.
- If you are measuring job offers, you are not considering how many people are "happily employed and have been so for many years." (Yes, it really does happen that way sometimes.
) In a corporate environment, a ColdFusion app might be in service, that has been in service for a long time and supported all that time by the same group of well-paid developers. - How much do the jobs pay!
Let's face it... competition does drive price, making a lot of "wild and wooly web" development a race to the bottom. But to be really good at writing CF-based internal applications, you've got to be really good at a lot of other things too. And, very likely, you will find yourself being well compensated for those skills. - That (especially in ColdFusion shops...) there are many technologies in use at the same time by the same people. A CF programmer might have other responsibilities and therefore have a job-title that does not say, "CF Developer." (One of the best developers around here has the title, "CIO." Seriously.) When you get ten or fifteen years (or more) "in," you're swapping between technologies like you're swapping hats, and you're doing that every day. A CF site might be presentng data from a COBOL program that you are also responsible to maintain. A dot-Net tool might be facing one way while a CF-based tool is facing another way, and you're tasked with both. Nothing to it. Par for the course.
I don't mean to be entirely crass when I observe that there are a great many junior-programmers out there who basically know "how to write the language" but do not know what to do with it. The job-pages are stuffed with those people, and with requisitions for them (because they're so darned numerous, they're both cheap and disposable). ColdFusion is not nearly so likely to be attracting and retaining that demographic.
AdChoices