Andrew's ramblings

Is Adobe killing the CFML language?

Tags: Coldfusion

I was thinking of sitting down and writing a response to the CFML advisory committee, instead I am going to find myself writing something based on not only that. But also a post by Alan Williamson as well, because it is related to what I was going to write about.

Let me first tackle Alan's post on Adobe is killing the CFML language.

Most of you will not know the history of CFML and its origins, there was a time when ColdFusion was not CFML and was actually DBML. So why is that important? It is important because the times have changed, the direction of the language has changed, and most importantly the thing that keeps ColdFusion alive is the support of the features that end up in the language. Without it CFML would have died a long time ago.

Should we keep calling the engine a CFML engine? In some regards Alan is right, technically speaking ColdFusion is no longer classified as a CFML engine anymore, and has ended up moving in a new direction. But to publicly claim that cfscript is not good for ColdFusion is going way to far.

Which brings me to what I wanted to talk about, and that is the improvements on CFML and also the improvements on cfscript and the future of the language, and the CFML committee and how blind sighted they actually are.

Lets look at the language and what is publicly available by the CFML committee, and it is no secret that the new version of ColdFusion will have every CFML tag available as a cfscript alternative. And this brings more problems that it actually solves, why is that?

Objects!! ColdFusion doesn't fully utilise what is under the hood, and that is the world of objects.

Lets take the basics of file and/or directory operations, we end up with a tag and now in ColdFusion 9 a function for all possible ways you need to do things. File and Directory operations would be better suited to objects because you could get a handler to the file system and then run a method as simple as the following code.

Instead what you will end up with is something that has to open a file/directory handler, close it when finished. And then maybe if you have a few loops to create directories you may find that it has to continually open new handlers, personally I can think of nothing worse than running extra computer cycles to achieve something so simple.

Oh wait a minute I can.. The unnecessary creation of more tags to over populate the language as it stands.

So why do I care, I care because when it boils down to it we are actually over bloating the language that will make it harder and harder to move away into something more desirable as a language.

For example lets look at what is being discussed on the CFML committee at the moment.

The debate over there could have bee easily solved if there was more forethought in the future direction of ColdFusion that what people are now asking for. What do I mean by that? I mean is that the needs to be a clear direction as to what is what in the language, and lets take a look at what we have under the hood of ColdFusion and how others have solved this.

Java is what ColdFusion is built upon, and it has not leveraged this in its fullest in almost 10 years, and I bet that it will be 5 more years before it begins to.

In the Java world java is used for the grunt, and JSP (Java Server Pages) is used to direct any type of output.

Grails and Groovy is the same, both use Java and groovy as the main language integration and again uses JSP for any type of output.

ColdFusion uses CFML and cfscript to do both, and that is going to be  huge problem for this language as it goes forward. So why is that a problem?

Head on over to Sean Corfield's blog or do a search for CFML committee, and you will see what I mean. Because there is no segregation between what is the grunt of the language and what is used for display, we have what can be described as on over complicated language when we need to integrate new features.

The discussion on mail and other tags is an example of that, and because Adobe chose to ignore objects and remain purely tags to this day as now hurt the language. I blogged about this once before, and today my stance has not changed.

ColdFusion needs to begin adopting the use of objects, and it also needs to begin segregating what is used for grunt (business logic) as well as what is used for output back to the browser.

And dare I say this one more time, ColdFusion also needs to look at adopting the likes of an MVC framework. Why do I say this? When you have more doors than locks, it invites to many ways to get into and hack an application. Adobe don't seem to care about that, and I fear that the new ORM features will be overlooked with Flash Builder integration as a priority because people are too lazy to write controllers that act as the front end to the database, once you go directly to the database you create more work in trying to protect your code and application that you really need to.

Tweet