I have been involved with our beloved CFML language for over 10 years now and in that period I have seen many a language come and go and still I prefer the power and simplicity of CFML. It just gets the job done. Sure it may not be as trendy or fashionable as Ruby or Grails, but I am proud to stand up and say I utilise CFML as part of my daily arsenal of tools for building software solutions.
... in the beginning
CFML like many languages of its day, started out as a single vendor product, from Allaire. A pure Windows based solution, it reduced the complexity of building dynamic web sites dramatically, pulling data in from remote databases a complete breeze. In those days the alternatives was not plentiful, or pretty.
In those days, the wonders of open source, or even open standards was something the industry was still getting to wide scale grips with. It just wasn't seen as the right business decision to set your Golden Goose free to roam the software highway.
That was really the seeds of why, in my view, CFML never truly reached the popularity the likes of php enjoyed. It was seen as a single-vender product. CFML over the years went through a number of different owners as bigger fish keep buying the holding company to the point where Adobe now control and own the original ColdFusion pedigree.
We, (tagServlet + New Atlanta), were the first commercial alternative to powering CFML files, using Java as the underlying platform to give us complete platform neutrality.
Where are the blue prints?
As any compiler engineer will tell you, writing a language runtime platform is not the easiest of software engineering tasks to take on. It is even harder, when there is no official language specification to refer to.
CFML as a language, or even a file format, had no formal documentation on what should or shouldn't happen. It had end user documentation on how to use the language, but that is a million miles away from a specification that actually lays out how a language should treat data, its lexical makeup, constructs, behaviour, limitations, extensions, etc.
So as an independent engine vendor, we simply had to go on what the "expected" result was. Let us call this the "conventional CFML wisdom". Conventional wisdom is something that is never written down, but we know it all exists and we all adhere to it (Freakonomics is a great book exploring this topic in society).
It is like dropping a stone down a well and listening for the splash.
In the early days we were continually amazed at the things you could do with CFML. At times we kinda looked at it and thought "mmm I wonder if they know it does that?". As a language, it does some pretty hairy things that suggest, that even Allaire/MacroMedia/Adobe don't have an official internal specification document.
With 10 years banked in CFML development we have come to learn one thing - be surprised at nothing. Even today, they are still making bizarre language decisions that has us (and some of the community) wondering what on earth is going on.
More kids on the block
So now, as a language goes, we are spoilt for choice, as we have a number of different vendors to choose from, offering a wide range of features and platforms to run on. There is no language that offers so much power, allowing your CFML application to run in any Java environment, including any .NET platform, plus running natively in the cloud on both Google's App Engine, and Microsoft's Azure platform. Even the almighty PHP can't lay claim to such versatility.
The two main camps are of course us, with (Open) BlueDragon (.net) and Railo with their Java implementation. Both camps have had no formal specfication to work from.
Yet here we all are, with fully mature production ready compatiable alternative CFML engines.
Adobe the unofficial official specification
The reality of course, at the moment, is that Adobe is the biggest fish in the CFML pond and it is in the interests of the smaller fish to swim with the bigger fish. That is not to say, the smaller fish aren't starting to not only swim aside the bigger fish, but in some instances lead the way, particularly when it comes to cloud innovation.
Open sourcing the engines has been a huge shift in thinking for the CFML community with us all attracting a legion of new developers who historically would never have touched a commercial only language. The community is benefiting from it as a whole. Active blogs, mailing lists and a healthy interest in our language helps everyone from the engine vendors right to the guys on the front line proudly putting CFML on their resumes.
I can't speak for other engine vendors, but for us, it is not in our (or yours) interest to not follow the additions and enchancements put forward with every Adobe release. We naturally, evaluate each and everyone, and think carefully if this is a feature that is going to be definitely used, or is something even they are trailing with to see how quickly it will be adopted. We listen to what you want and if you want something that another engine has, then of course we will implement.
You are the specification lead.
We wanted a language specification
In the early years, we were very vocal about wanting to formalize a language specification. We wanted to take CFML to an official standards body and get it officially recognized. We approached the owner of Cold Fusion many a time, but each time, they weren't interested. It wasn't really in their commercial interest to make it easier for alternative vendors to pop up.
As it was, it was difficult to create a true CFML engine, and it was really a case of survival of the fittest for those that did succeed.
A language specification would have caused them more problems than it tried to solve. It would have highlighted just how much inconsistancies there was in the underlying language, that to highlight that as a "must implement" feature would be near on impossible. Also, you had to weigh up the fact that with every release, particular from 4.5 up to 7, they would regularly break stuff that use to work.
A new dawn?
A couple of years ago, the notion of a specification raised its head once more. There was more people at the party now so maybe this time it had a chance to succeed. A committee was formed, that met in a private-only mailing list, with representatives from only some of the engines. OpenBD, eventually, having a seat at the table.
Much was written about how successful this group was going to be and how they would transform the language so all the vendors could be sure they were producing compatiable runtimes. Just like the start of a new presidency, there was much hope, back slapping and general good cheer.
It is now 2010, the CFML2009 specification has all been but abandoned, with the committee focusing on 2010 or even a 2012 standard. No one really knows what is going on, or even how active the committee really is. Maybe it should take a leaf out of the Java JCP process and open up its archives and become a public read-only mailing list so the very developers that will be using the initiatives they debate about can see how their language is evolving.
Personally, I admire their efforts, but I for one do not see the need for a formal specification. Not now after 10 years of doing this. We don't need one. Adobe is the specification. Period.
Who does a specification really benefit?
I think it is important to look at the bigger picture and ask who really needs a specification. Over the last six months I have spoken to many CFML thought leaders (including a fascinating phone call with Adam Lehman, CFML Product Manager, at Adobe just before Christmas). Each and everyone has had their own take on the future of CFML and the strengths we all exhibit. Let me assure you, it has never been a better time for our language history.
To answer the question, it is easier to look at the broad categories of people who are involved with CFML.
- CFML Developers
The most important person is the one cranking out CFML applications to satisfy their customers wants, putting food on their table in the process. These people traditionally stick to one engine. They rarely create truly engine-agnostic solutions. Once they are completely familiar with a particular engines setup, configuration, performance, weaknesses, strengths, it is in their interests to get on with the job at hand of writing CFML applications. For this group, a specification doesn't help them too much, for once they have choosen their engine, they rarely move.
- Framework Developers
Framework developers are those people that create libraries of CFML code to ease some of the bigger tasks. Fusebox and MachII for example, take away a lot of the common tasks associated with building web apps. They are generally not aligned to a particular engine as they wish to cast as wide a net as possible to encourage more users to their platform. A specification for this group helps a lot. But that said, they are also in the best position to play to a particular engines strengths abstracting that away from the top-level developer.
- Engine Developers
A language specification would naturally help the open source projects initially, but in the long term may get in the way of innovation as specifications take a horrendous amount of time to ratify. At the moment we all "evolve" to a given "conventional wisdom" as to how something should manifest itself. So while it would be handy, it is certainly not stiffling language improvements. If one engine has a function that another one doesn't have, and a user recommends it should, then the respective engine also implements their own.
In the end, the only people to really get a boost from a specification is the framework developers, who in reality are a very small subset of people. At the moment, the engines are compatiable enough for the CFML developer at large to easily move between engines, without too much fuss.
"engines are compatiable enough"
It is not in the business interests of Adobe to be forced to implement a specification that it doesn't have final veto over. The CFML Committee is structured in such a way that whatever happens their voice is heard the loudest. So if Adobe can overrule any decision, then it kinda makes the whole committee somewhat pointless. There is no pressure on them to implement any of the recommendations and they will listen to their large corporate clients long before the input from a few alternative engine vendors.
Adobe, as someone once said, aren't in the business of saving the whales. They are a commercial organization designed from the start to make money and return value for their shareholders. They need to keep the lights running just like any other business and are not immune to forced layoffs. They are not going to turn their backs on the wants of their paying clients.
Adobe are not immune to the effect of the alternative engine vendors. They have implemented many a new feature that we as BlueDragon have introduced to the language and while we may differ with the odd attribute here and there, it isn't really a huge deal.
The reality of the situation is that Adobe is the official CFML standard, and I as one of the alternative engine vendors am actually very comfortable with that. It is in our interests to keep as compatiable as possible and that healthy competition benefits the CFML developer.
Collaboration is good
I believe the CFML Specification is an admirable effort, but in its current format it is doomed for failure. To succeed, it should reposition itself as a CFML Guidelines committee. An open forum for every one to contribute to how they feel the language should evolve. Everyone has a say, everyone gets heard, with the engine vendors listening and reacting accordingly. We can all see the "conventional wisdom" that bubbles up.
To that end, I have created a Google Group that I encourage you to sign-up and contribute to - a completely engine vendor neutral mailing list.
Let us all join in on the conversation on how we want to see the CFML language evolve. As they say, history is made by those that turn up.