ColdFusion debate on whether cfscript should be more like ActionScript, again!

Tags: Coldfusion, ColdFusion 9

I am going to have to say that I am going to have to agree with Ben Forta on one issue, anything that can make cfscript be more productive to us as a developer is always a good move.

However writing ActionScript would be disastrous to ColdFusion in ways that people are not willing to think about.

The last time this debate came up there are so many people, and blogs, that support this move. But in reality the only reason that these people are supporting it, is because they believe learning two languages is a bad thing.

These people believe that going from one language to another when developing Flex/ColdFusion makes it harder, and is also the only reason that Adobe are considering this change. If you read between the lines of what Ben Forta has mentioned, Adobe are looking at ways to bring a lot more people from the Flash/Flex/ActionScript world over to ColdFusion. It would be that sort of blindness that would actually kill the product going forward, because how could this change even warrant being more productive?

What Adobe should be thinking about to enhance cfscript is look at how to leverage Java in a more productive manner.

As it stands now we are a scripting tool, running on top of Java with a slap hazard way to leverage the underlying engine. When ColdFusion 9 improved the script to use the import for package like file inclusion and the new operator, I was stoked as it saved so much work than using the createObject function.

But what disappointed me was that I can't do anything like this.

import java.io.*;
var f;
f=new File("myfile.txt");
if(!f.exists()&& f.length()<0)
writeOutput("The specified file is not exist");
else{
finp=new FileInputStream(f);
byte b;
do{
b=finp.read();
writeOutput(b);
}
while(b!=-1);
finp.close();
}
}

Notice how we have a mixture of Java and ColdFusion there, without having to have modified the code too much? The original Java code would have looked like this.

File f;
f=new File("myfile.txt");
if(!f.exists()&& f.length()<0)
System.out.println("The specified file is not exist");
else{
FileInputStream finp=new FileInputStream(f);
byte b;
do{
b=(byte)finp.read();
System.out.print((char)b);
}
while(b!=-1);
finp.close();
}
}

In its current state if you want to use Java objects you are still forced to use the createObject function, as the import and new operator don't understand Java at the moment.

In conclusion I would find that grabbing a Java code snippet and just dropping it into my code, would be far more productive than if I had to rewrite this in ActionScript. But hey this is only my opinion on the matter.


TweetBacks

RT @cfbloggers ColdFusion debate on whether cfscript should be more like ActionScript, again! - http://cfbloggers.org/?c=47419 Feb 5, 2011
ColdFusion debate on whether cfscript should be more like ActionScript, again! - http://cfbloggers.org/?c=47419 Feb 5, 2011

Comments (Moderated) | Add Comment

  • shirak's Gravatar CFScript is one of my favorite enhancements in CF9. Previously our .Net and Java developers were not interested to look into CF code when it was tag base. After the enhancement I did to rebuild the services in OOP way using cfscript, now actually they are maintaining it.

    I totally agree to have action script inside ColdFusion Engine as alternative not as replacement to CFScript. Flex developers would love to have one value object not 2 as it is today (as,CFC).

    Let's face it, what is the point to bring Java coding inside CF while CF can extend by Java and cfscript looks like java already. You can call most Java libraries inside CF. In addition to that I don't believe CF will attract Java developers to CF they both are great server side technology. But consider Flasher and flex developers they really need server side technology to work with, and CF should be their first choice.
    # Posted By shirak | 2/5/11 11:51 AM
  • Andrew Scott's Gravatar Yeah I am loving cfscript in ColdFusion 9, not only is it quicker to develop with but it actually executes faster, from what I have been hearing.

    But I strongly do believe that they could help us developers out more, reduce the size of the foot print of a war deployment, and allow us to leverage of Java more easily than we can now.

    I don't think there is any point creating new functions, just because we seem to not be able to leverage it from the underlying engine.

    I mean

    file = createObject('java',java.io.File');

    is longer to type than

    file = new java.io.file;

    Now that would make cfscript more productive to me, and it would also promote more use of java, and begin to reduce the footprint of ColdFusion as well. There is already a debate going on about the size of the war file for deployment in the cloud, and ColdFusion is consider heavy for this type of deployment.

    By allowing what I suggest a lot of the size of ColdFusion will be reduced because of this very small enhancement.
    # Posted By Andrew Scott | 2/5/11 6:16 PM
  • Justin Carter's Gravatar The single value object case is a bit weak - and it could just as easily apply to JavaScript objects (write once, use client side and server side).

    In addition to that, if Flash and Flex developers don't already use ColdFusion for their server-side stuff then they probably aren't going to start if/when ColdFusion gets ActionScript as an alternative server-side language. CF is probably the easiest tool for the job already, so perhaps they have other reasons for not choosing it - the lack of server-side ActionScript isn't it though, IMO.

    I'd much rather see cfscript get finished properly.
    # Posted By Justin Carter | 2/6/11 6:11 AM
  • Andrew Scott's Gravatar I have to agree Justin, if the Flex/Flash guys are not using ColdFusion now they probably never will.

    But what is finishing it properly going to entail, that is the question. Sure there are missing tags, you can't type arguments in a function with a CFC name, or I believe as a return type either.

    Anything else I might be missing.
    # Posted By Andrew Scott | 2/6/11 6:21 AM
  • Justin Carter's Gravatar Yep, those things you mention plus a couple of others I think...

    In cfscript, queries are slower than cfquery (the CF side of things obviously, not the actual communication with the database), and they are more verbose. This could fix those two issues (though the first could possibly be fixed by a native implementation of rather than a CFC wrapper):

    http://www.madfellas.com/blog/index.cfm/2011/1/26/...

    Custom tags are also forgotten. The above method could allow some of them to be used in cfscript. For e.g. in FarCry Core there are a certain things that are implemented using custom tags for good reasons (flexibility, avoiding messy loops or switches in code, etc). I'm sure MXUnit has a bunch of custom tags that  A method for using a block of custom tags would also be welcome.

    There is also some inconsistency/ugliness with cfscript equivalents implemented as keywords and as functions, something that might need to be cleaned up:

    http://twitter.com/#!/cfchris/status/29720536963620864

    There are probably other things that others have come across as well. I think they're definitely important enough things to be sorted out before alternative scripting languages are introduced.
    # Posted By Justin Carter | 2/6/11 4:31 PM
  • Andrew Scott's Gravatar Which is why I am a big advocate of proper closure support in ColdFusion, not to sure how it would really be implemented but it would be nice to do something like this.

       def xml = {
          def persons = Person.list()
          def writer = new StringWriter()
          def builder = new MarkupBuilder(writer)

          builder.people {
             persons.each { item ->
                builder.person(id: item.id) {
                   firstName(item.firstName)
                   lastName(item.lastName)
                   email(item.email)
                }
             }
          }


          [ personXml: writer.toString() ]
       }

    Now although this is grails/groovy style it fits and is very flexiable, I think the biggest problem is when we can't separate views/controllers/logic, as it promotes bad style code that we have to continue to support for the rest of its life.

    I sort of like what you C4X is trying to achieve, but I think rather than trying to solve the current problem with badly designed language, we need to look at redesigning it to work correctly, which is why Grails is so damn nice.

    And I am sure that the best minds can come along and see something like this as being an improvement, and adopt something close to grails syntax that would work well with ColdFusion. But it can only happen if ColdFusion begins to become an OO language as its core.





    # Posted By Andrew Scott | 2/6/11 8:14 PM

Comments (Moderated) | Add Comment