Everyone freshly stuffed from their various dinners and socializing, we all waited in anticipation for the start of this evening's Birds Of a Feather session entitled "The Future of CFML". The zeal and comaraderie of the group was alive and well in the room (as are all such meetings involving members of this community) when the three panelists/moderators seated themselves in front of the room. On the left was seated Gert from Railo; in the center was Matt from OpenBD, and on the right was Sean Corfield. I couldn't help but wonder amusedly if the shirt Sean was wearing was prophetic in its short, simple statement: "I See Dead Code". Not so much that CFML could ever go extinct, but I wondered in myself whether or not the mother of all CFML, Adobe herself, might one day become a matter of history regarding the evolution of our language.

Just prior to formally beginning the discussion there was a brief but loud bump at the room's emergency exit. Upon inspecting the source of the noise, we happily found it to be a man bearing a large smile and at least two cases of Shiner Bock and other miscellaneous recreational beverages, no doubt just exactly the elixir needed to facilitate this discussion and keep it well lubricated. After the initial distribution of holy water, Gert formally got the dialogue rolling.

He began by giving us a short, general list of what he hoped to accomplish with the meeting, primary of which was to receive input from the rest of us as to what features and/or changes we felt the open source CFML engines needed to incorporate. He laughingly also allowed us the benefit of airing any grievances we may be harboring as well, the implied subject being Adobe and her less than friendly stance towards the open source engines. Speaking of whom, it was shared with us that the conference hosts had spoken with Adobe and extended an invitation to participate in whatever manner they saw fit. They saw fit not to participate at all, their motivation being (sadly so) that they had no place at an open source conference.

At Gert's checkered flag, the conversation was immediately off and racing full speed ahead. With courtesy abounding and caring moderation conducting this orchestra, nearly everyone had at least one thing to share with the group. In between listening, considering, and sharing, I was busy taking notes on how this dialogue flowed. What follows is a very paraphrased approximation of how it all played out, with my occasional commentary interspersed and annotated as such.

Upon the news that Adobe had declined to be represented among us, I couldn't help but feel a very strong sense of apathy towards her, looking into the future and feeling quite confident that, with the open source engines maintaining such a tight bond with the community who symbiotically supports them, nobody would shed a tear or be left in any kind of a lurch if Adobe should disappear from the CFML landscape tomorrow. Gert was sincerely gracious in reiterating to me at one point that, in its present state, CFML could not survive as a language if it weren't for Adobe's continued participation in its evolution. Despite his kindness towards Adobe, I could still envision the day when Railo and OpenBD would be leading the way for Adobe rather than the Adobe setting the standards for the open source engines.

The first topic was introduced by Sean, and addressed the fact that, the way CFML is currently architected, one basically has EVERY available tag and function living within the same namespace; that is, at any place and at any time in any CF app, you can execute ANY CFML tag or function. When you think about this, it seems like a lot of overkill to have EVERYTHING imported, especially when the model of other languages is that you only import what it is you need. Thus, Sean suggested that perhaps functionality be segregated into importable packages or modules.

Noting that, given any length of time when someone wasn't audibly speaking, the topic was subject to sudden and immediate change, the next tangent embarked upon was converting some functions to objects. For instance, there are currently 80 separate functions that you can use to manipulate spreadsheets in CFML; but it was suggested that it might make more sense if those functions were part of a single spreadsheet object that a developer could simply create an instance of and then call the needed methods in a more object oriented manner. It would remove those functions from the global namespace, alow those objects to be used within CFSCRIPT, and it would give developers a more "sensible" and compact syntax for writing code.

Someone then spoke of ways to measure the success of an open source engine's progress, and the popular response to that question was "the more hostile Adobe gets, the more successful that engine is becoming". Indeed.

Being able to execute different languages within CFML has been a topic of discussion off and on over the years, and we all took the time to hash it out tonight as a group. Languages such as PHP, Groovy, ActionScript...wouldn't it be useful to be able to execute their code directly within a CFML template? Well, it is definitely do-able, and has been demonstrated time and time again. Sometimes it is of use, with specific use cases; but the real question is, would end users truly find this a useful thing to have? How often would one really want to suddenly switch up and run a few lines of PHP within a CFML page? Just because we CAN do this thing, SHOULD we? Looking to the example of Adobe, who, in wanting to help attract more Flash developer to CFML, invested the effort into making it possible to execute Action Script on the server side. And did their effort succeed in attaining their goals? Did a million plus Flash developers fall in love with CFML? No. In fact, many of the Adobe Flash applications and demos are embedded in PHP pages. The overall conclusion to the debate led to a pretty clear "no, we do not need to make this feature part of the core engine". When such needs do arise, CFCs can be written to wrap up and provide this functionality, such as has been done with CFGroovy.

This discussion necessarily led to discussing OTHER tags that have been made part of the core that probably aren't appropriate as well. Tags such as CFMap, CFAjax, CFSharePoint, CFForm, CFTable were mentioned by name, though the list is much longer. Quite frankly, most developers do not and will not use these tags. Due to the fact that so many legacy apps exist, one person suggested that perhaps these "smelly" tags could be moved out of the core and into a "grandpa" library that could be imported as needed to support backwards compatibility. The nay sayers of this, though, brought up the subject of simple deprecation (or defecation, as one of my peers shared) of certain tags and functions. As with many languages and projects, there comes a time in their evolution when backwards compatibility can and should only go so far. So, rather than worry about legacy apps breaking if one were to upgrade to a more current engine, put the onus back on the developers to weigh out whether or not they're willing to simply rewrite the affected portions of their code to be compatible with the engine version they desire. It's not a new thing at all, and it makes perfect sense in the natural order of things. The now deprecated CFML advisory committee was nearly unanimous on this idea, with the exception of one member who tended to oppose sound suggestions on a rather frequent basis to suit their own needs.

A developer who is fairly new to CFML shared her perspective on the language, conferences, and what it is she does and does not look for from the community with regards to help. She was very pleasant and candid, and was interested in having access to a resource where she could get information and help with the kinds of projects she is specifically working on. This led the discussion into a debate on some kind of centralized wiki for CFML. There are those who feel that the current landscape dotted with blogs whose content tends to be very ecclectic in nature just wasn't sufficient to act as a solid resource for those who are just getting started with CFML. I personally thought contrary and, though I am all for a "central repository" of knowledge, feel that a virtual one is just as good as a tangible one. In over 13 years of CFML development, I have worked primarily as a lone developer and as such have had to seek out the information I needed as I went along. Google, ah my good friend Google, HAS been my single virtual "central repository", helping me locate exactly what I needed from among the multitude of knowledge out there, and helping me to make some good friends in the community along the way. This debate then evolved into discussing ways to assist one another. It was said that if you find there is only one person in an organization that everybody else goes to for help, it is possible for this to become a source for the propogation of poor coding habits. It is healthier for the community as a whole, therefore, if every individual makes a conscious effort to seek out assistance from different people, whether a local peer or a virtual one. The idea of what appropriate help is was also explored. In a nutshell, if you're doing it for them, you're not helping them. Give them the clues they need to figure it out for themselves...teach 'em to fish, don't catch it for them!

Ah, and speaking of educating people about CFML, a healthy discussion on ways to incorporate more of the other languages' communities also took place. In a nutshell, CFML has had a bad rap pretty much since its beginnings due almost completely to the fact that it never had an open source engine and required major financial investment to use. Now that this is no longer an issue, it's time the world became aware. How can we do this? By doing what I interpreted from the conversation to be an ethical bait and switch. Two key areas stood out to me during this dialogue: blogging and code sharing.

Regarding blogging, Sean put it best when he said that as long as you only blog about CFML, then only CFML developers will be reading your blog. The point therefore being to get developers of other languages reading your blog and thus "discovering" or even rediscovering CFML, it is important to do a couple of things. One, do more to genericize your blog. Rather than name your site something CFML-specific, like "BestColdFusionSiteInTheWorld.com", try "codeMonkey" or something else that speaks as well to a PHP developer as a CFML developer. Rather than title your posts with something CFML specific, try to come up with more generic approaches to sharing the information in your post. It's okay to mention CFML in the post, but get their attention first with your vast knowledge of ORMs, MVC, object oriented principles, and THEN utilize CFML to illustrate what you're talking about. Also, take the time once in a while to learn about and blog about other languages or technologies. On my own site, for instance, I get a LOT of traffic to posts I've done on Oracle, CSS, Javascript, and PHP. Sean shared an example of how he has gotten increased traffic via his posts on Clojure and how some of those readers have actually commented to the affect that they discovered or rediscovered CFML via his site.

Many community members share projects they've created. Custom tags, CFCs, entire apps. Applying the same mentality described with blogging, Sean suggests that rather than simply host your shared code on RIAForge or other CFML-specific sites, share it on Github! That way, EVERYBODY will see it. The more visitors to Github see CFML projects rising on the list, the more attention it will gain.

Lastly regarding attracting outside developers is the idea of participating in technical forums that are language agnostic, specifically StackOverflow. As other language developers frequent that site and see CFML questions being posted and responded to, it will undoubtedly pique their curiosity!

In a nutshell, all of us can facilitate the CFML Rennaissance by simply making a few simple changes to our online habits.

We wrapped up the session by actually talking about the main topic that Gert had mentioned to begin with: feature suggestions. Some of those shared were the incorporation of closures, proper collections and enumerables, and heredoc syntax.

Lastly, we were all given the reminder to take the time to share our ideas, needs, and desires for the open source CFML engines. The open source community, as it always has been and always will be, considers themselves to be one with the community who utilizes them. They recognize and embrace the symbiosis that makes both we and they great: mutual evolution.

Oh, I mentioned the CFML Advisory committee that had been formed to help all of the CFML engines evolve with some kind of standardization. Since Adobe refused to participate and exercised a lot more vetoing than concurrence, the new unofficial yet very functional CFML advisory committee exists in the form of a Google group to which ALL are invited to participate and be heard. If you have any input, ideas, or rainbow and lollipop dreams for either Railo or OpenBD, feel free to interact with those who guide them at CFML-CONVENTIONAL-WISDOM (http://groups.google.com/group/cfml-conventional-wisdom?pli=1)

Doug out! :)

P.S. Notice that not one time (with one exception when referring to what not to do on your blog) did I ever refer to our language as ColdFusion. As I believe that Adobe will one day in the near future no longer be leading the pack of engines, I prefer to think of ourlanguage in a more generic, open source fashion. This necessitates the cutting of all ties, and thus I will, on most every occasion from here on out, refer to it only as CFML. Might as well get used to changing your mindset to something more open source as well! :)

First of all, you're not worthy to sport a name with "of America" in it, so if I weren't so interested in this post showing up in Google searches for you, I would simply refer to you as Bank of Suckbutt. Since I do want as many people as possible to find this post, though, I shall use your full name. Additionally, I'll preface this post with a simple yet entirely accurate insult: YOU SUCK!

My first interaction with Bank of America was some years ago when I worked for a temp agency doing data entry. I was paid by check, and since at that time I had no bank of my own at which to cash said check, I went to my employer's bank where they would surely honor the check since they were the issuers of it. I waited in line in the marble floored cathedral that was Bank of America's lobby, and happily approached the teller when my turn arrived. I should have gained some insight as to the type of institution Bank of America was simply by the look of suffering that decorated my teller's brow, but it wasn't until I was told that there would be a "cashing fee" of ten dollars that I was able to accurately conclude that Bank of America was a parasitic, oppressive, extortionist in the guise of a bank. Not having any choice in the matter, I allowed them their pound of flesh and left, vowing never to enter their doors again and, at every opportunity, to give them the woeful review that was due them.

I kept my vow (as I am so prone to do) and never once had any interaction with them again, as well as smearing their name whenever banking was the subject. Then two years ago, I bought a house and found to my chagrin that my mortgage had been immediately sold to Bank of America. The first thing they did was to calculate my taxes based on a school district located a good 30 miles away from me. After hours of phone conversations (the majority of which were spent navigating cryptic automated menus and listening to bad hold music), I was forced to do their job for them and acquire and submit proof of the actual applicable school district. They adjusted our mortgage to reflect their "best estimates" of the amount of escrow we would need at the end of the year, and raised our mortgage to an amount that was a little higher, yet still within our budget. That year came and went, and after they had paid the taxes on our behalf, they recalculated the amount they felt we would need for next year. Since they had overpaid our escrow account by $900 the previous year, they then lowered our mortgage by about $200 a month. When tax time came around again, they discovered that they had woefully underestimated the amount and so had to pay out of their own pocket. After realizing their mistake, they then took the amount they were short, divided it by 12, and added it to our mortgage, raising our mortgage by nearly $400 a month!

Coupling my past experience with Bank of America with the horrendous mismanagement and blatant ignorance displayed in the handling of our mortgage was enough in itself to cause my wife and I to seek refinancing with a reputable institution. But, when you also consider the recent accusations of fraud, illegal foreclosures, and newsworthy possibility of bankruptcy by Bank of America, it is in my opinion a VERY bad idea for anyone to remain their customer in any capacity. Internally, they are crumbling; the morale of Bank of America employees must also necessarily be suffering, the results of which manifest itself as apathy and mistakes that WE...you, I, and anybody else unfortunate enough to be in a financial relationship with Bank of America...have to pay for in one way or another. My recommendation and urging then to anybody who reads this is, if you are currently associated with Bank of America, JUMP SHIP IMMEDIATELY! If you are not, then make it a point to always steer clear of them. There are plenty of stable, reputable financial institutions out there who make customer service their number one priority. Why settle for an abusive relationship when you can have one that is fulfilling and beneficial?

Bank of America, you suck, and you are doomed by your own founding principles of treating your customers like mindless, soulless sheep to fall and crumble into extinction. The world will be a MUCH better place without your unscrupulous extorionistic practices in it, and I (along with multitudes of others) will personally rejoice in the day that you are no longer in business.

On a side note, my recommendation (based on my own personal experiences) is a twofold path. The most recommended path is for those who can qualify for membership to USAA. They are nationwide, stable, and without a doubt have built their reputation upon their passion for customer service. I'm not sure of all the details on qualification, but for the most part you either have to have been in the military or be related to someone at the grandparent level or closer who is or was. Out of desperation to get away from Bank of America, my wife and I called them up to talk about refinancing and within 20 minutes of nothing more than a phone conversation had been approved and the paperwork in the works to be Fed-Ex'd to us within two days.

If you're not able to join USAA, my next recommendation is to join your nearest Credit Union. Unlike banks, they seem to be MUCH less interested in extracting fees from you and are more of a "bank of the people". Credit unions will all have their own criteria for joining, but typically it isn't difficult at all to qualify for membership in most of them.

If anybody else has had experiences with Bank of America that they'd like to share, please do post them in the comments below! It's important that they be exposed for what they are in the hopes that perhaps some may be spared the damage that their unprofessionalism and internal decay can cause.