I mentioned Sean Corfield's thread on last week, it now has over 30 comments, and is very compelling reading. But my own take on is a little different, let me explain ... was originally created to make ColdFusion more palatable to developers using traditional scripting languages (Perl was the example thrown around back then). The intent back then was to provide these developers with a syntax that they'd be more comfortable in, in an effort to sway them to consider ColdFusion. That did not happen. Why it did not is another subject (but at its simplest, PHP is the heir to Perl). And so we were left with a partially implemented that some ColdFusion developers loved but most ignored. That's the history part of the post. today is in a strange place. There is nothing that can do that CFML tags cannot do (which was not the case pre-CFMX), and there are no real performance gains in using (which, again, was not always the case pre-CFMX). It is not even ideally suited for creating UDFs anymore (UDFs created using tags are far more powerful and are generally preferred). It is now purely an alternative syntax to a subset of CFML functionality. There are lots of enhancements that users want, all valid and all reasonable. And so with each new version of ColdFusion the team sits down to determine the features that will, won't, and might make it in to the release. The process is a long and tiring one, it involves prioritizing requests, and assigning resource costs to each. Over and over again we have to weigh the relative costs and benefits of features so as to determine what is in and what is out (and yes, for every feature that is in something else is out). And without fail, every time we go through the process we look at all the requests and ask ourselves "are we better off adding feature X, something that cannot be done in ColdFusion currently, or improving what is essentially another way to do something that you can already do?". And every time, without fail, we vote to add the new functionality. It's not that we don't see the value of , and more that we usually see it as less valuable than whatever we are weighing it up against. That is not to say that we'll never update , we have indeed made incremental enhancements where appropriate and justified. But complete language support for both tags and , well, having been through this many times by now, I just don't see it happening any time soon. (Of course, this is my own opinion, others may feel otherwise, in which case we'll be having lots more of those long and tiring meetings in the future).
My Take on CFSCRIPT
29 Comments
D
Darryl Lyons
What about people who code in ActionScript and CFscript? Shouldn't there be some sort of consistency in syntax between the two?
E.g.
In ActionScript you would write this:
for(i=0; i<10; i++) {
...
}
and in CFSCRIPT you would write this:
for (i=0; i LT 10; i=i+1) {
...
}
A
Alex Sherwood
On further thought, CFML's strength is that its a RAD tool/language. Making as much of the core functionality as possible available via CFSCRIPT, you hold true to CF's roots.
Plus, you might get a larger number of traditional scripters to the CFML camp, and help them overcome their sick, perverted and deviant aversion to tag-based languages. ;-)
B
Ben Forta
I empathize ...
I wrote a spec way back when that defined functions for every just about every CF tag, and each function took a single command structure with the name=value pairs. Sweet stuff. Oh, I also then proposed that CFML tags take that same structure instead of only name=value pairs. But, when it comes down to it, as cool as that would be, I'd not want it at the expense of anything else.
N
Nolan
While I get Macromedia/Ben's side of things, I too would like to see more support in CFscript.
I'm a C/C++ guy originally, and the syntax still appeals to me more than CFML, least for business logic. I like using "tags" for "tag things" (display layer, HTML) and keep my actual logic in CFscript -- just a personal preference.
Fortunately, there are things like CFlib where people have been contributing CFscript alternatives for features that were once CFML only (cfquery, etc), so at least we have that for some of it.
I also really liked it when CFscript was faster than CFML (and still seem to see some instances where that's true on CFMX, but maybe i'm on crack), it felt like those of us "in the know" had this secret optimization trick. :)
2 cents.
D
Darryl Lyons
I don't think I would have done much with CFMX in terms of upgrading CFSCRIPT given that it was such a big change in architectures.
However, I think that these days a lot more people are developing with ColdFusion, and the MX products are quite frankly more well known. When you are competing with other languages such as ASP and PHP it makes sense to me to support more well accepted syntax like <,>,!= operators (as an example).
In terms of tag support, you could just write UDFs as wrappers for CFQUERY, etc.
A
Alex Sherwood
Don't worry about being faciteous....a bit of jocularity is good now and again!
I don't know what I would have pulled. What would make the most sense would be to take the most common, widely used TAGS and port them to CFSCRIPT.
One thing I do realize is that tags make it easy to name attributes. CFSCRIPT equivalents would only be useful if thay accepted argument by order and not name, and you know that opens a can of nasty worms.
I know CFQUERY comes has been requested tons, but again, you've got the hassle of all of the arguments to deal with.
I guess in the end new features would probably make the most sense, when money and time are factored in. If Blackstone takes off, however, hopefully MACR's bottom line will afford new features AND enhanced CFSCRIPT for CF8, code named "CFSCRIPTStone". ;-)
B
Ben Forta
Alex, I did not quite say "go by the wayside", but ...
Think back to CFMX/CFMX6.1. What would you have pulled fro the release, sacrificed for CFSCRIPT? I am not trying to be factitious, I'd really like to hear how others would prioritize features and requests.
A
Alex Sherwood
This is not good news. I might be in the minority, but I use CFSCRIPT whenever and were ever I can. It's less typing, more compact, and much easier to read.
Whats more is that I started my career with CFML. I know BASIC and a bit for FORTRAN, but I was never heavily into a script-based language before I learned CFML.
I'd hate to see CFSCRIPT go by the wayside. The TRY/CATCH functionality added in CF5 (I think) was a huge boost, and I use it tons. I often find myself olnly abandoning CFSCRIPT when I * HAVE * to use a tag in my code, and event then I'll have CFSCRIPT blocks before and after the tag call when possible.
Sat it ain't so, Ben!
A
Aidan Sherrin
Forgive me if this has been mentioned already. I for one would love to see better CFScript support and I am amazed to find out that I am not the only one.
I've been think why this is, and the only reason I can come up with is that ColdFusion developers are evoluting. When most of us started using ColdFusion and fell in love with it, we were "junior" programmers. During the past years though we've gotten better. The best programmers have never never liked ColdFusion because of it simplicity and lack of control over what happens(Note: I'm not saying that everyone who uses something other than ColdFusion is a very good programmer, but that ColdFusion attract junior programmers first and foremost). As we are getting better and more knowledgeable though, we want more advance features and more control.
<CFSCRIPT> would be, in my opinion, a great way to please the current programmers allowing them to write more structured code. Obviously the functionality has already been written, and its just a matter of witting a compiler which understands the syntax. This should be rather easy for an engineer who understands parsers, since once more they will only be witting a syntax analyzer which performs functionality already written by others.
Macromedia is constantly attracting new, junior level, developers/customers. There's an obvious big business doing this. They are increasingly losing the developers which they've had for long time.
I love the product and wish it continued success.
A
Adam Cameron
Regarding:
Think back to CFMX/CFMX6.1. What would you have pulled fro the release, sacrificed for CFSCRIPT?
From CFMX, I probably would not have pulled anything, but I would have preferred if CFCs from the outset were more-Java-a-like:
<cffunction name="foo" returntype="string" access="public">
<cfargument name="bar" type="numeric" default="1">
</cffunction>
Instead:
public string foo(int bar=1){
// stuff
}
From BlackStone? I'd probably keep the gateways and would chuck everything else in favour of more CFSCRIPT. Truly.
Regarding:
There is nothing that <CFSCRIPT> can do that CFML tags cannot do (which was not the case pre-CFMX)
So there's a <cfcontinue> tag I didn't know about?
For my part (opinion): CFML is just pig-ugly, and wastes a lot of space unnecessarily. But I can live with that. Just wish I didn't have to, that's all ;-)
Adam
D
Daniel, SIlva
Just to avoid misinterpretations, i'm _NOT_ suggesting that cfscript should substitute in anyway cfml, it should complement it.
I can stop saying, i love Flex's programming model !
And as i said on Sean's blog, i'm not talking about an 1to1 relationship between cfscript and cfml, rather a 1to1 relationship between fulcral cfml tags/constructs and cfscript.
I'm realist, i know it would be hard and resource intensive to hv a 100% tag compliant cfscript, at least within one release timeframe.
Cheers,
Daniel
D
Daniel, SIlva
Ben you totally got me wrong, or i didn't explained myself well enough, either way, i wasn't trying to say that Coldfusion would gain a lot more focus just by 'upgrading' cfscript, we all now that even when one thing is theoreticly perfect it takes many time until it gets widely accepted.
But to me, it *really* would help to encourage users from different platforms, maybe not to complete migrate from the it, but at least consider Coldfusion as viable solution.
Doing PHP for a living for some years now, i've heard many opinions about cf from php developers and the top reason why they dont like Coldfusion is just this one, they think coldfusion as a newbie language that uses tags for its syntax, when they look to the source of a cfm file they really laugh at me, they cannot understand that using tags is simple and straight forward, even if i show them why.
I was _NEVER_ allowed to use Coldfusion in any project for a portuguese ( yes im portuguese ) client - i only know 2 companies that use cf - and only 1 hosting company that offers national CF hosting, CF5, and only because it came as an free extra when they bought their servers.
There is a huge reluctance about Coldfusion, partially because of its RAD nature and "programming model" - if i can call it this way.
I say it again, im not saying that php/asp/whatever developers will start to come in flocks just because MM revamps cfscript, i do however say that it would help to make cf more atractive to developers from other platforms, more than some features MM so emphasize and say "we didnt updated cfscript because we wanted to add new exciting features", when in the end many of the users wont be using it eitherway, because they were thought for the enterprise market.
Maybe im wrong and my opinion is influenced by geographic/social/economical differences or even be biased because i hv a 'strong' PHP background, but for me, and for what i've been told about fellow developers from my country hv told me, cfscript would be a "great and exciting new feature".
Cheers,
Daniel
D
Darryl Lyons
Ben, surely all of the comments on this blog and Sean's blog about CFSCRIPT should show that large number of developers want to see some consistency between the languages?
Perhaps a poll at MXDU? :)
B
Ben Forta
Daniel, just so I am clear, you are suggesting that if ColdFusion code could be written in a way that looked more like PHP and ASP, then suddenly PHP and ASP developers will migrate to ColdFusion en masse? And if so, what evidence do you have to back that up? Don't get me wrong, I am not downplaying the appeal of CFSCRIPT in any way, but at the same time I don't think that your plan will work. Do you?
D
Daniel, SIlva
Whatever you say, Coldfusion is loosing ground to competing technologies like PHP, ASP .NET and alike, let's take AnandTech for an exmaple, once a high profile Coldfusion website, now still a high profile - or even bigger - but now powered by ASP .NET.
CFscript is not just about giving some developers and alternate way to code, it's about marketing .. isn't it all about marketing ?
CFScript would help coldfusion's user base to grow by opening doors to PHP, ASP .NET, Perl, <insert your scripting monkey here> coders. A bigger user base would help to create more commercial products using cf, would help to create new or support existing Open Source projects or even port projects, more users more popularity, more popularity more revenue.
Am i all that wrong by thinking this way ?
Cheers,
Daniel
B
Ben Forta
Jonathan, that is incorrect. CreateObject() can be used with a simple <CFSET> and you have the exact same component persistence. And you don't even need CreateObject(), <CFOBJECT> will allow it to, just specify a NAME in a persistent scope.
As for making <CFSCRIPT> more like ActionScript, that's one that has come up before, and we started down this road with server-side ActionScript in CFMX. For the most part the response to that was tepid at best, but in all fairness, there was not enough of it to really gauge reactions.
J
Johnathan Gifford
I think Darryl L. put it best. How about some consistency with action script. Or better yet, how about porting a large number of the action script 2.0 features into cfscript usage.
If scripting were to be consistent across all development environments (Flash, ColdFusion, Director) with a core set of functionality available to all, WOW. Powerfull integration of products through a common language for Macromedia. Have a seasoned ColdFusion developer, also now have junior Flash developer. Basically a guy who understands the syntax and language of Macromedia Action Script.
I took a Flash class last summer that went over the ActionScript 2.0 in depth. All I could think about, was 'what if this was in CFSCRIPT for the next ColdFusion release?' Cool... Then I saw Blackstone Cool... Hey, wait where's the action script stuff? Especially if were getting flash forms?
Don't want to beat a dead horse, but <cfscript> does have it's advantages the with 6.1, COMPONENTS.
<cfinvoke> is a great tag, but you can't take advantage of the one great thing components offer, persistence. I cannot persist a <cfinvoke> after I call it. Using createObject() I can.
<cfscript> makes if much easier to write code calling components like objects passing them around from one call to another. I can even store values and information then save that component to a session variable and then pick it up and doing more with it later on another page. Ah the power of persistent objects.
Yeah I can do it with <cfset> an dreamweaver helps code it just as fast, but it doesn't look as clean as it does with <cfscript>. Ah, to make our code more Java like in the melting pot of ColdFusion.
B
Brian Rinaldi
I use cfscript primarily for appearance sake as I find it is much easier to read. Therefore, I much prefer the added features than cfscript updates. Thankfully sites like cflib.org tend to provide most of the additional functionality I require.
D
Darryl Lyons
Nolan, I would only expect to see those type of operators within CFSCRIPT.
R
Roland Collins
I don't need radical revisions to CFSCRIPT - I'd just settle for a throw() function!!! It's amazing to me that we've had try/catch for so long, and still no throw!
N
Nolan
Darryl, yes and no (if i may be so bold as to speak as if i know what i'm talking about! :)
i see your point, and it would make learning/using the different MM languages simpler if they were all the same.
i'm pretty sure one of the reasons CFscript is different in those operators is because the parser has to look for open/closed HTML tags and using "<" or ">" in comparisons would throw the compiler way off.
there may be other reasons in addition to, or instead of that one, but that's the one that pops into my head and seems to make sense, at least to me.
M
Mike Klepper
ColdFusion server implements server-side ActionScript; perhaps this can be leveraged for CFScript purposes?
M
Massimo Foti
I often use <cfscript> because I find it easier to read.
The only thing I miss badly is throw(). All the rest would be nice but I understand the need to give priority to new functionalities.
BTW Since we are here, support for "finally", both in tag and script syntax would be handy too.
Massimo
M
Mike Gardiner
From reading various MM employee's responses to the issue of enhancing CFSCRIPT it seems to boil down to one thing -> Time & Money. It should really be about Investment & Return.
So to Ben,Sean C. and other Macromedians I suggest instead of viewing it as a question of "how many people are going to drop asp/php/whatever and come to CF because of cfscript" think of it in terms of "how many people have been turned away who might have chosen CF had it looked more familiar to them".
How many flash/website developers might have been told by their boss "personalise the customer pages with their data" and after looking over CF saw that it was tag based and bore no resemblance to the script language they currently use.
How hard could it be to expose many of the core tags through built in cfc's or a basic cftag object model? At the very least give us standard operators like &gt; &lt; !! && ++ etc to save me 2.5 minutes a day from wasted debugging! :P
J
john ivanoff
I like cf because I can use a cfquery tag instead of writing 12(or so) lines of code to do the same thing in asp. to have many lines of code to look 'smart' doesn't make since to me. I hope I don't ever have to debug that.
J
john ivanoff
I like cf because I can use a cfquery tag instead of writing 12(or so) lines of code to do the same thing in asp. to have many lines of code to look 'smart' doesn't make since to me. I hope I don't ever have to debug that.
P
Phillip B. Holmes
CFScript needs to be expanded if anything. MM: listen to your clients. CFScript is keeping your hardcore scripters in with CF. Deprecate it and you'll lose market share.
B
Bobby L. Heath
In my opinion cfscript is coldfusion's saving grace. There is something to be said for clear, concise syntax. Not to mention the RAD value cfscript presents. Any time you can do something in less keystrokes you get more of the Rapid in the RAD. That is what coldfusion is for, isn't it. I personally use cfscript any and everywhere I can and will have to reconsider using coldfusion at all if it becomes deprecated. I just have very little desire to sift through business logic that consists of tags.
M
mkruger
Ben - I'm not concerned with CF Scripts "compliancy" with a particular scripting standard, but I do not want to see it go away either. With the advent of CFC's I find myself writing "event handlers" (In this case - blocks of code that figure out what to do next) that are implemented mostly in cfscript - because they can be nicely encapsulated and commented and the total size of the template can be reduced. That's where I find them most useful. You can encapsulate CF tags and use them in scripts etc - although I haven't found that terrible useful (except for CFDUMP - it's nice to use that inside of a script block). The only glaring weakness is my inability to figure out how to do true error trapping in spite of the 'try' implementation. But maybe that's just me (ha).