Coldfusion is a dying technology?

My CTO just annouced that we are going to migrate all our coldfusion applications to .net platform by the end of the year, which means that, we (4 coldfusion programmers), will either have to find a new job, or start learning asp .net by end of this year.

Adobe, please do something about coldfusion, you can keep rebutting or counterargue about the "Coldfusion is dying" statement, but please do some really fundamental reality check. Coldfusion is really a superb language, and I don't want you to end up like Nokia, or blackberry. PLEASE....

It's just like a debate, not seem like discussion :-s.

Your comment about "dirt-cheap labor" is prescient.  And, "you get what you pay for."

There are lies, damned lies, and ... statistics like these.  Perfect for selling your educational materials or your $50 book or your trade school, to folks who fondly imagine that if they can make a credible use for this-or-that buzzword (which you, of course, are very happy to sell them...), the world will beat a path to their door.  There are lots of people out there who think that way.

"Your job" is to be a hospital sysadmin ... not to be "a ColdFusion programmer."  So, you're not going to be on the radar of that statistic anyhow.  Since you, and thousands of folks just like you, don't even appear as a blip on their scope, the picture that it paints is meaningless.

Thank you for the clarification (regarding XML).

There are several aspects which these graphs do not consider:

1. 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.
2. 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.
3. 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.
4. 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.
   
5. 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.

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"

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.

Ansury wrote: Not my words.  I've been told this by someone else. Detecting more than a hint of bull, I figured I'd ask here.  How true (or false) is this statement?  If it is dying, what's replacing it?  Random thoughts on the state of CF's popularity welcome.

Never mind. Here's a scene from Woody Allen's Annie Hall.

Those that have been going on about Coldfusion's impending death remind  me of nine-year-old Alvy. Like Alvy, some stopped doing homework for their employer.

Doctor in Brooklyn: Why are you depressed, Alvy?
Alvy's Mom: Tell Dr. Flicker.
[Young Alvy sits, his head down - his mother answers for him]
Alvy's Mom: It's something he read.
Doctor in Brooklyn: Something he read, huh?
Alvy at 9: [his head still down] The universe is expanding.
Doctor in Brooklyn: The universe is expanding?
Alvy at 9: Well, the universe is everything, and if it's expanding, someday it will break apart and that would be the end of everything!
Alvy's Mom: What is that your business?
[she turns back to the doctor]
Alvy's Mom: He stopped doing his homework!
Alvy at 9: What's the point?
Alvy's Mom: What has the universe got to do with it? You're here in Brooklyn! Brooklyn is not expanding!
Doctor in Brooklyn: It won't be expanding for billions of years yet, Alvy. And we've gotta try to enjoy ourselves while we're here!

I heard this a couple years ago from a bum that was trying to pushing for Visual Studio 2008 (CF8 was still a new releas).  Considering all the products that work with CF, I would suggest that anyone who claims that it is "a dying technology" is either misinformed, lying, or using some very "interesting" (and most likely illegal) substances.

Nobody in the history of the planet has ever said that CF was dying. It is ALWAYS second or third hand information.

There was an article penned a few years ago by a non-programmer citing that CF was dead. Nobody had ever heard of the author. There was no evidence that the author had ever programmed in any language, let alone CF. The article was cited all over the web as the death knoll of CF. An unknown author with unknown credentials with unfounded statements, and the story went viral.

Here we are a few years later having the same conversation. There is obviously not a DNR order in place.

I agree with Ian.

As for the "dying technology" bit ... computer software does not "die."  A piece of computer software might have a lifespan of twenty years or more.  Companies go to great lengths to evolve their technology strategy without replacing (almost) anything about it.  The software is a mission-critical investment of many millions of dollars.  And, it works.

Experienced practitioners switch languages as easily as they change their hats, and they pick-up new technologies on the fly (as I did) because they have accumulated a depth of prior experience to which "the latest thing, whatever it is," always relates.  Sure, you might spend your days at a particular company working with whatever technologies they've decided to use ... and yet, you flip back-and-forth among several technologies without thinking too much about it.  ("Is a woodworker limited only to a chisel?")  ("It isn't what you got ... it's what you do with it.")

You know the game:  times change, accountants do what accountants (often) do "to cut costs" and ... oops!  buh-bye!! ... and-d-d you twist in the air and land on your feet and this time it's an altogether different set of technologies, so you read a manual over the weekend and start right in.  So it goes.  From one "dying technology" to the next ... and, lo!, ain't none of 'em dead yet.