Her are the results:
Q1: Are you involved in upgrading CF sites when new versions of ColdFusion are released?
First up: most people have been involved in upgrades. Well: most people who read this (fairly obscure) ColdFusion blog do. This is no surprise I guess. Well maybe the 1% "no" is the surprise here. Perhaps they are recent adopters and already have CF9 (I personally see no compelling reason to upgrade from 9 to 10), or CF10.
This highlights one really obvious question I forgot to ask: what version are you currently running! However I have a more comprehensive surrey pending asking that question.
Q2: Which of the migration paths below have you undertaken?
[I need to tweak the charts a bit here, as the answers are overflowing the area I've allocated for them to display in. And there's another occurrence of this further down. I'm still learning Zingchart formatting, sorry]
The next question was just getting a feel for which versions of CF people have migrated from, and the path they took. The key points here being the oldest version people has used, and whether people tend to upgrade one version at a time, or jump across versions. Personally I've been involved in upgrading from everything from CF5 (I started on 4.5.2, but never had a hand in the upgrade of that to CF5), through each version to 9.0.1. I've always jumped one version at a time. The spread was fairly even across all versions of CF, and all migration paths.
There were a few "other" answers here. Three of them cited "other", but then listed one of the options already provided (maybe my wording was obscure), the other was relevant: they'd upgraded/crossgraded from ColdFusion to Railo. I've added that as a slice in the piechart, as it's a valid response I overlooked to have a specific option for. No-one suggested they'd up-/cross-graded from CF to OpenBD.
Q3: Which of the statements below best reflects your reasons for upgrading ColdFusion?
Next is the reason to upgrade. Here's where I wasn't able to predict the results. I would have expected more people to be in the "don't upgrade if my current app works fine" bracket, but perhaps whilst that might be the case (or it might not be!) in the broader CF install-base, it might not be amongst community participants I guess. Also not so many people think "staying on a supported version" is the key driver, as I would have thought would be the case. The bulk of people are after bug fixes or features. I wonder which? I should have made that two options: that seems really obvious to me now. Some people wanted to be on the latest version seemingly "just because": not because its bug fixes and features, nor because of the support life cycle. I wonder what the rationale is there?
There were a coupla interesting comments:
"To take advantage of new features & bugfixes", but the features need to be compelling. Short of 'compelling' I'm willing to stay on an old version until security forces the issue.That makes sense. The other comment was:
I wanted to have everything on Railo since its faster and freeFair enough. I think we'll see more of this if Adobe doesn't stay competitive.
Q4: On the whole, which of the statements below best describes your re-work requirements (eg: to solve incompatibilities arising from changes in ColdFusion) from CF upgrades?
I don't think there are any surprises here. There's almost always some rework involved. Whilst this demonstrates that all these attempts at maintaining backwards compat on Adobe's part don't actually succeed, I guess given that the effort people perceive there to be is minimal, it suggests they are doing a pretty good job. No-one's reported an unacceptable amount of rework.
My anecdote is that when upgrading from C8 to CF9.0.1 recently, we were bitten on the bum by a completely unnecessary change to <cfabort> that Adobe introduced without any consideration of backwards compat at all. I guess this demonstrates two things:
- they should consider backwards compat;
- but I suspect it's something they roll out as an excuse not to do some work as much as it being really really important to them. Because they'd not have messed with <cfabort> if backwards compat was really that important. I mean: they can't have run regression tests before that change, can they? Regression tests would be absolutely critical to preserving backwards compatibility.
There were a few comments against this one, and they speak for themselves:
We used a mix of CF7 and PHP, as CF didn't have the features we needed. We switched to CF9 to stop using PHP, and also make more use of the CFScript features which were massively improved in 9
When upgrading from CF8 to CF9, arrayFind() was introduced. We had an arrayFind() UDF that was conflicting. Same with FileDelete(), FileWrite(), etc.
Half the projects needed no re-working, the rest needed minor tweaks.
Hit & miss depending on the application. Often, it takes no rework.
A little re-work was needed from 9 -> because they removed Verity. A lot more re-work was needed 8->9 because they implemented tags that I already had UDFs for (isNull) that worked differently than the CF function.
Q5: The current specifics of CFML aside, which style of syntax do you personally prefer from those listed below?
Now we're getting into an example of moving CFML forward at the possible expense of backwards compatibility, and the need to deprecate things. This was just a change someone had mentioned that I think would be a good idea, but would be likely to raise flags of "backwards compat" with Adobe.
I got a swag of comments with this one (I guess because I actively solicited them on this question). The bulk were along these lines:
- it matches how CF code has gone, with CFCs using object.method() syntax;
- it matches other languages in CF's sphere of relevance;
- the procedural approach is a bit out-dated;
- it makes more sense (this is obviously more subjective than the other answers, but a bunch of people said it)
Another person answered "does it matter?" I'm sorry, but that's just a stupid thing to say. It might not matter to you, no. And that's fair enough. So in that case the answer is "It doesn't matter to me", but to ask - in a rhetorical fashion - "does it matter?" is patronising and dismissive. Clearly it matters to some people. Only a f*ckwit would answer like that.
There was a couple of people who said something along the lines of "well I learned function(object) syntax years ago, so why change?". So I guess it's not just the language that is possibly stagnating.
Q6: Which of the statements below best describes your understanding of a feature being "deprecated"?
In this question I was just gauging what people's understanding of "deprecation" is. Because a lot of people think that if something is deprecated that means their code will immediately start breaking. Which is absolultely not the case. Note: parameterExists() has been deprecated in CFML since CFMX6.0 (I thought it was already deprecated in CF5, but I'll bow to the docs here). It still works. So if Adobe were to start deprecating some of the baggage in CF, we could legitimately expect to quite possibly still be working in CF15.
Note: a couple of the people answering "other" both specified "removed within 1-2 releases", so I reflected their answer as a separate category in the chart, despite it not being one of the options I initially asked.
Q7: If, in a move to modernise its syntax, Adobe was to change CFML syntax from function(object, args) to object.method(args), and DEPRECATE existing function(object, args) syntax, which of the following is closest to your reaction?
People seem to be OK with the notion of deprecating stuff in favour of keeping the language current (57%), but that's only a slim majority. So I guess - given blogs attract more forward-thinking members of a community - then perhaps the bigger picture across people who are more work-a-day CF developers rather than community participants, this might not be a majority position. That said, the work-a-day people could also possibly just shrug and go "OK..." and crack on with the new code, or not be the sorts of people who stay up to date with CF versions anyhow. Also, bear in mind if the existing functionality still exists but is just deprecated, everyone's code will still work, but people can leverage more modern coding practices and styles which suit their needs/wants. Everyone is happy.
There were quite a few comments here too:
I really don't care which syntax is used as long as it is consistent. Right now it is not and this causes a lot of frustration for veteran CF developers as well as those new to the language. Pick on approach and do it well. There a lot of other weird things in the language I'd target first. Null support for one.
The most important thing is for CF to get consitsent, I don't like the difference between location(url) and include template="path" in cfscript, and the fact that cfloop requires query="nopoundsymbols" and then array is different, array="#varname#"
Do it, make sure Adobe provides a list of what is changing so that we can do a global search/replace. :P
Deprecate, but not remove would be my preferred.
If by depricate, it's available but not recommended, that's fine. I've too large a code base to refactor everything to object syntax. However, if there were also a CFAdmin switch that "turned off" function style, that could work also.
As long as the old way still works
Should have happened long time ago already
If they depreciated it then it would be helpful if they gave a guaranteed minimum number of years or versions where it wouldn't be removed. It would be nice to know existing apps could be upgraded to CFn+2 to take advantage of new features without worrying about re-writes because of syntax changes.
Still compatible, but lets us use an easier syntax. I'm for it.
Adobe has other things to do first. Marketing!
Other great ideas: 1) drop any UI from the core. Things such as cfwindow, cfchart, etc... should be depreciated and eventually removed. There's too many free HTML5 chart engines out there for me to have to buy an enterprise license of CF for. 2) Rework cfscript syntax for things like properties/attributes (i.e. param name="something default="something"; should be something like param.new({ name: "something", default: "something" }) or something like that. 3) Scrap and redo the cfscript way of cfquery.
I agree with the one about marketing. Well I agree with all of it, but the marketing one is a good observation.
Q8: Which of the statements below most closely matches your your opinion of Adobe's "Holy Grail" of maintaining backwards compatibility “at all costs”?
This was my main question. I believe that Adobe are slightly too cautious in places, and could ease up on the "holy grail" thing. I went for the "The policy is reasonable, but..." option. Other people made some good comments:
It *has* caused some stagnation in the language, too.
It is very important between versions, but there needs to be a path forward that drops some of the accumulated bloat.
A re-branding is needed as people associate CFML with the 90s. Easier to come up with a new language with the deprecations and new enforcements.
At my company, our team has three programmers who do CF, only one of whom does it full time. We support nearly 200 CF applications across 6 production servers. Most of these applications were written years ago by developers who are long gone. It is simply not feasable for us to have to make this kind of a change to all of our apps. Deprecating the existing functionality would not help, as it would be nearly impossible to justify to the business the expense of making this change unless we knew for certain that it was going away. I prefer the syntax you are proposing, but I just don't think it's worth the effort.
every library / language has breaking changes. thats life
Fine for a few versions back, but at the point Adobe stops supporting that version then "at all costs" is extreme as a policy!
Actually they should have a switch that turns off (and removes from memory) the deprecated stuff. However one thing that I would not remove is what you are articulating. Nor would I favor script over tags. However there is a lot of stuff like flash forms and cf2,3,4 cruft that would result in a leaner and meaner CF. But if the default was compatibility it wouldn't break code. I know people that religiously upgrade but are running CF-2 era code ;<) Why should Adobe not keep cashing their checks?
I would bet that the majority of CF installs are NOT recent versions. I recently refused work because the company was still using CF5. I told them they were wasting time and money paying anyone to build advanced functionality on 5 when it would take a few minutes on 9 (or 10). It would make more sense to drop backward compatibility at a major release and move forward.
Their most important clients are probably US public sector, so you can't expect them to go against their wishes.
Hi Adam, Ben Forta has always defended backwards compat/keeping the UI and other cra...cruft saying it's vital to a big constituency of their customer base who aren't pro-developers, but business types who just want to knock stuff out quickly and not have to maintain/refactor. I guess they do have to please that significant market segment. Shame for the rest of us and the ongoing health of the language, but then again I chose CF 15 years ago precisely because I wasn't a pro-developer at the time but needed to get stuff done quickly, and the alternatives were too "techie" for me. I'd love to see the cfFat trimmed and the syntax sanitised, but I wonder if it's possible without fundamentally changing the nature of the (Allaire/MM/Adobe) product. Cheers [name removed] PS: I wanted to post this as a comment on your blog post, but the commenting profile options on Blogger are too limiting (I don't want to use my Google ID, and I don't have any of the others).
I don't care how it's done but for several versions adobe needs to ship a backward compatible version and a non backward compatible version that drops all the old stuff and jetisons the js inspired tags and flash forms. The overwhelming number will move forward in my opinion.
ColdFusion needs to born again itself and start over, making some ( many? ) compatibility sacrifices in order to become the single best option on the market. Do everything right, amputate the fat, focus on back end, not front end ( with the exception of Web Sockets ), and KILL IT.
Performance can be an issue because of this
I do think that the policy applying to code that's 10 to 15 years old is stretching it a bit. What percentage of businesses would want to port a project that old to the latest version of CF? Pretty low I imagine. Even if they did then they'd probably want a re-write just to impliment new functionality into the site and take advantage of more modern programming practices.
it has caused me to look more closely at railo and start moving my ACF servers to railo.
we move our apps to the new versions as quickly as we can when new versions come out, after testing. This makes the app not backwards compatible, but this is not an issue.
That said, there does still seem to be this undercurrent of just not getting what deprecation means. The functionality doesn't go away! No-one is saying anything should be removed from the language! Personally, I would remove a bunch of stuff, but I respect Adobe's approach with deprecation (leaving stuff in), but I think they don't exercise this option often enough. You can be happy with your old legacy systems (which probably don't have their CF versions updated anyhow!), or writing CF2.0-style code. However it also means the rest of us that give a sh!t about the language moving forward get a chance for it to progress. And maybe stop losing ground against other languages (although I think this is probably mostly a marketing and cost issue).
I dunno what to take from this, but it was interesting seeing what people think.
And now I need to scarper, so I'll abruptly finish this here.
[time passes]
I am back from the engagement I needed to scarper towards, and have infilled some more commentary. On reflection - I had come out as very against Adobe's "backwards compat at all costs" position - I think I have lightened up slightly on this. However I still think "intertia for the sake of backwards compat" is not something Adobe ought to fall back on, and I do think they fall back on it (and even use it as a work-avoidance tactic sometimes, although I concede this is just a feeling, and based on nothing). If the language needs smartening-up: do it. Don't be so afraid of potentially breaking old code that will possibly never see a CF-engine upgrade anyhow. This is perhaps something that doesn't occur to people: changes in CF11 will only impact situations in which servers are actually upgraded to CF11 (CF11 being just an example). A lot of this code that would be broken by non-backward compatible changes in CF11 will not actually be affected, because servers running old code are not usually the ones that get upgraded every release.
I'm actually not that pleased with myself in the questions I chose to ask in this survey. Some were obvious, some were a bit obscure, and some were meaningless outside of context I didn't think to ask about. But it's all a learning curve (like everything else on this blog), and I do appreciate people taking the time to answer this survey. I'm not just saying that, I do really appreciate it. I'm quite chuffed you chose to help out. So thanks for that. And bear with me: the surveys should improve.
--
Adam
