5 ms·

Why is that frightening as opposed to any other older web server code/api that is out there? Or even newer code for that matter?

lostapathy 10y ago
All the ColdFusion code I've ran into still exists because it's too rotten of a mess to be replaced. 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.
- bluetwo 10y ago
  I maintain a large codebase for an application that has been around for longer than a decade in CF. I love it. 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.
  - lostapathy 10y ago
    I agree, it's not really the language's fault. I'm involved with more than one application that's over a decade old, so I understand what happens. 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.
- ambicapter 10y ago
  Why would you want to replace a "healthy" codebase?
  - lostapathy 10y ago
    You wouldn't. I'm just observing that none of the CF I've had to deal with is healthy - it's all a mess they want to replace. Probably poor wording in my prior comment that was hard to parse as intended, apologies.
  - askvictor 10y ago
    To take advantage of modern technologies? To be able to hire coders? That's two off the top of my head, I'm sure there are plenty of arguments both ways. 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
PeCaN 10y ago
So there's run-of-the-mill old code that's accumulated a lot of cruft, is hard to get acquainted with, and can be tedious to work with. But it works, and doesn't get replaced. 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.)
- lostapathy 10y ago
  This, exactly. 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.

lostapathy 10y ago

All the ColdFusion code I've ran into still exists because it's too rotten of a mess to be replaced. 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.

bluetwo 10y ago
I maintain a large codebase for an application that has been around for longer than a decade in CF. I love it. 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.
- lostapathy 10y ago
  I agree, it's not really the language's fault. I'm involved with more than one application that's over a decade old, so I understand what happens. 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.
ambicapter 10y ago
Why would you want to replace a "healthy" codebase?
- lostapathy 10y ago
  You wouldn't. I'm just observing that none of the CF I've had to deal with is healthy - it's all a mess they want to replace. Probably poor wording in my prior comment that was hard to parse as intended, apologies.
- askvictor 10y ago
  To take advantage of modern technologies? To be able to hire coders? That's two off the top of my head, I'm sure there are plenty of arguments both ways. 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

PeCaN 10y ago

So there's run-of-the-mill old code that's accumulated a lot of cruft, is hard to get acquainted with, and can be tedious to work with. But it works, and doesn't get replaced. 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.)

lostapathy 10y ago
This, exactly. 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.