I mentioned Sean Corfield’s thread on
But my own take on
There are lots of enhancements that
That is not to say that we’ll never update
My Take on CFSCRIPT
29 responses to “My Take on CFSCRIPT”
-
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! -
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. -
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". 😉 -
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. -
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. -
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. -
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. 😉 -
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) {
…
} -
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. -
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!
-
Nolan, I would only expect to see those type of operators within CFSCRIPT.
-
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.
-
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. -
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. -
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 -
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?
-
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? 🙂 -
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 -
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 -
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 -
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. -
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.
-
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.
-
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 > < !! && ++ etc to save me 2.5 minutes a day from wasted debugging! 😛 -
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 -
ColdFusion server implements server-side ActionScript; perhaps this can be leveraged for CFScript purposes?
-
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.
-
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.
-
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).
Leave a Reply