Back in the age of classic ASP, Perl scripts and CGI scripts, Cold Fusion was a very decent technology choice. It was my introduction to a controller/view styled programming pattern (called Fusebox) back in 2000.
Then they (Macromedia) got bought out by Adobe and the whole thing descended into weirdness and MS came out with .Net.
Now get off my lawn you millenial! :-)
Why? If it was in demand due to scarcity, couldn't you have done freelance work at a ridiculously high hourly rate? I've come across another ol Indian dude (my Pop's age, we called him 'uncle') who was making a killing programming in some mainframe language called COBOL.
Answer this and I'll get off your lawn LOL.
( He also made fun of my node.js and react.js and said "You young kids are always moving on to the next shiny thing")
It depends how old you mean, but if you're a few years away from retirement it could still be a good plan.
Love this phrase! I'm a Millennial, so I have ways to go, but this makes sense for when I hit my early 50s (if I am still alive and well that is)
It has evolved to be a Java Framework, essentially, but I love it still.
Once you get into practice of using coldfusion components, which compile into java beans, it becomes the best of all worlds. Stable, easy to read and write, highly reusable, lots of functionality and expandability, fast, compiled, etc.
If more people did this we wouldn't be solving the same problems over and over again.
It tends to be very procedural code with lots of "libraries" that rely on side-effects rather than abstraction. The kind of thing where nobody understands how core concerns (like security) work, they just "know" it seems to work. Except those in the know, know that it doesn't always work, but it's all too fragile to fix it, either.
I know I've been extremely unlucky with the CF code I've had to deal with, but I've also never heard of anybody with a healthy CF codebase they aren't eager to replace.
I have also, over the years, been brought in to rescue applications that have grown into giant messes. So I'm not saying what you are saying is incorrect, but it has less to do with the language, in my opinion, and more to do with what happens to large applications that get written by multiple teams of people over the years, as they adapt to changing customer demands.
And, sometimes, by managers who don't understand code, the importance of documentation, or how to communicate and plan for business issues.
Build an app in any web application today and try to maintain it for a decade.
My point is that a lot of the things still running around in ColdFusion aren't there because they're healthy, they're around because they are too sick to do anything else with. I've got too much personal experience with applications used by the government that I sure would not trust with my personal data! You know, things written before password hashing was standard practice ... and that still don't hash passwords.
Presumably if your codebase is healthy, there is structure and documentation that would make it comparatively easy to replace in a different framework as requirements evolve. Unhealthy codebases don't have this so that stick around without adapting/evolving
Then there's old code that barely worked when it was new and is held together by duct tape. Often it's written in something antiquated like VB6 or COBOL and is very troublesome to replace. (Not that all VB6 or COBOL code is bad, mind you, but as soon as you get out of their problem domain things go downhill fast.)
Then there's ColdFusion.
--
(In all seriousness, I'm sure there's good ColdFusion code out there, but the stuff I've seen is like a weird mish-mash of all the bad parts of PHP with all the bad parts of ORMs and all the bad parts of XSLT.)
It's like a case study in all the bad things that can go wrong when you mix government projects run by people who didn't know what they were doing with 10-15 years of neglect, but need to keep the software alive because it supports a critical government function but there's nowhere near the budget to rebuild it properly.
We have in large part just superseded it with some small static html+js sites dedicated to each of our products that we stuck on Azure webapps. So much easier, so much better, and, so much cheaper. But the main site limps along.