Scott Stroz wrote on 04/14/06 1:04 PM

I can say that I have never written an app that uses even one line of <cfscript>, thogh I have had to work with/debug a few.

I agree, I don't like it either.

I undertsnad that there was a time that <cfscript> offered a performance boost, but, if I remember correctly, that advantage went away in CFMX?

Jared Rypka-Hauer wrote on 04/14/06 1:14 PM

Personally I like using CFSCRIPT for everything, and I always wrap my queryies in special UDFs:

<cfscript>
dsn = getDsn();
myData = qryGetFoo(dsn);

if (myData.recordCount) {
msg = "We found data!";
} else {
msg = "Luzr, you ain't got no data!";
}
</cfscript>

<cffunction name="qryGetFoo" returntype="query" output="false">
<cfargument name="dsn" type="dsn" required="true" />
<cfset var qry = 0>
<cfset var rslt = structNew()>
<cfquery name="getFoo" datasource="#arguments.dsn.getName()#" result="rslt">
...
</cfquery>
<cfreturn getFoo />
</cfquery>

See? See how elegant and how OO I can make my procedural ColdFusion applications? I've encapsulated my query, I've passed in parameters, I've even var'ed my variables to keep them from leaking into the variables scope! I don't even mind writing an extra 5-10 lines of code per query because it looks hardcore. I tell people all the time that "real" OO doesn't exist, that it's a fantasy, and that this is what "real programming" is all about.

I mean, honestly, there's never been a successful OO project, and MVC is a silly idea promoted by amateurs and uber-geeks who just want to make this stuff so hard that "normal" people can't keep up. I'm just trying to look out for the little guy here.

;)

Laterz,
J

Matt Woodward wrote on 04/14/06 1:20 PM

Although I don't love cfscript as much as you seem to hate it ;-), if I have a ton of stuff that's just just "logic" code (switches, if/else, etc.) or a ton of cfsets in a row, I'll throw that into script because A) it's less typing and B) it's easier *for me personally* to read. That said my brain doesn't explode if I encounter an app that doesn't use cfscript at all.

Sean Corfield wrote on 04/14/06 1:23 PM

Oh, this is going to be an interesting thread...!

I'm on record as saying I wish Macromedia (back when I said it) would deprecate cfscript so my feelings are pretty well known :)

I never normally use cfscript for anything - for all the reasons Joe lists - however, Fusebox 4.x is mostly cfscript (which gives me a headache reading the core files - no offence JCQ!) and for Fusebox 5, the custom lexicon verbs are actually more cleanly written in cfscript - because they are purely cfscript. The "core" of Fusebox 5 is all tags (apart from two pseudo-constructor blocks that were actually code lifted from the Fusebox 4.x core files).

Roger Lancefield wrote on 04/14/06 1:28 PM

I think I agree. Either go with ECMA Script syntax and operators, and fully flesh-out CFScript functionally (a task which Sean C. has pointed out, is anything but trivial), or else depracate it.

My use of CFScript has shrunk to trivial stylistic uses, such as using <cfscript> blocks to delineate var-declared variables at the top of CFC methods, thus making them more visually prominent. Hardly the most technically demanding use.

Joe Rinehart wrote on 04/14/06 1:32 PM

Jared, you crack me the heck up.

Jared Rypka-Hauer wrote on 04/14/06 1:32 PM

Scott, you are indeed correct.

When CF was run on a C++ runtime, cfscript offered a performance boost over the tag-based alternatives. Consequently many people developed a cfscript addiction that, like any other addiction, is pernicious and unrelenting.

However, now that nothing runs "natively" in CF (in that it's all compiled down to Java bytecode and then run within the J2EE server as Java), there is no performance boost and cfscript is kept around for backward compatibility. In fact, the cfscript and CFML alternatives are compiled down to the exact same Java constructs... so there is zero realized performance benefit and often more verbose code.

NOTE: The livedocs recognize cfscript as a distinct language, separate from CFML.

http://livedocs.macromedia.com/coldfusion/7/htmldocs/00000970.htm

Laterz!

Terrence Ryan wrote on 04/14/06 1:35 PM

I remember that in CF 5 cfscript was definately faster for certain operations. So I have a lot of code that was writen with that in mind, then brought up to current version and left in cfscript format.

That being said, I agree with you that cfscript is less desirable.

Daniel Roberts wrote on 04/14/06 1:38 PM

I started using CFScript when it was released because there was a performance benefit and it hadn't been long since working in C so it was a bit easier to read to me. Now I don't use it at all.

Jared Rypka-Hauer wrote on 04/14/06 1:44 PM

I still use it, like Roger and Matt, in places where there's going to be a finger-numbing set of cfsets and other tag constructs that don't have a lot of benefit to all that extra text...

<cfscript>
var foo = "foobar";
var bar = "barfoo";
var slinky = "a wonderful toy";
var bigTxt = foo & "," & bar & "," & slinky;
</cfscript>

That's actually 10 fewer characters than the "<cfset " alternative... plus the visual difference between the morass of tags and the fairly legible collection of sets. But actually using it to write the guts of the application? What a massive waste of time! You have to work HARD to cover all of cfscripts deficits, and there is absolutely no way to get a simple ECMA-style language like cfscript to be as robust as you can with tags and attributes.

Bah on the whole idea. ;0

Laterz,
J

Dave Carabetta wrote on 04/14/06 1:51 PM

I think that the issue with cfscript is more the engineers' fault at Allaire/Macromedia/Adobe. They essentially started a project that they never finished. If they had decided to go feature-for-feature between cfscript and the tag-based syntax, then it would have its place. Rather, they left it bastardized and it has just sat around while the rest of the language was made richer. Hence, I would agree with Sean that it should have just been deprecated with the MX 6 release. It's kind of like IE 6 vs. Firefox. At one point, IE was good, but has since been wildly surpassed because it was just left to stagnate.

We have a Python guy here at my company who just doesn't like the tags -- he's all about using cfscript because script-based syntax is more familiar to him. Remember, not everybody starts in ColdFusion, so there are a lot of prejudices for converts (or dabblers, in this case) based on what they're already used to. I use to use cfscript a lot, but now the first thing I do when I go back to old code (and have time) is move it out to the tag-based syntax for consistency. I don't hate it -- but it's clear that it's provided "as-is" and isn't going anywhere either.

Joe Rinehart wrote on 04/14/06 1:54 PM

Hey Dave,

All good points. Only thing I have to say back is that I do remember that not everyone starts in CF - I didn't start in it, and sometimes still feel most at home in ECMA-inspired environments.

Steve Bryant wrote on 04/14/06 2:05 PM

Joe,

All valid points. Personally, I *like* cfscript. I find it easier to read (in certain situations where there is no output).

On the other hand, I probably use cfscript more than I should. When I run into trouble, it can cause headaches because it is harder to throw a <cfdump><cfabort> or <cfthrow> in the middle of my cfscript logic (which can sometimes be helpful when debugging).

dave ross wrote on 04/14/06 2:12 PM

I agree wholeheartedly. <cfscript/> should be deprecated.

john Wilker wrote on 04/14/06 2:12 PM

I have no idea where I picked it up, but I tend to only use cfscript in cfcs. Maybe it's a carry over from JS, function in js, function in cfc, I don't know.

At any rate. i can take it or leave it, but like mentioned above, it's also easy for my brain to digest large blocks of control type logic in a script block.

Who knows.

Dave Carabetta wrote on 04/14/06 2:13 PM

Oh, I was referring to the comments in general, not necessarily your comments regarding previous experience. I know that you've got a varied background, but many CF-ers don't, so I was making the point more to them should they be reading the comments!

Barneyb wrote on 04/14/06 2:45 PM

For certain things, CFSCRIPT can be very useful. If you've got a huge pile of CFSETs, you can use CFSCRIPT to cut out not just a lot of typing, but a lot of clutter. The less-verbose argument applies everywhere, of course, but I'm of the opinion that unless you do a "block" ALL in CFSCRIPT, none of it should be. For example, a CFC method. Some of them are well suited to CFSCRIPT-only implementation, and why not if it'll save you a few hundred keystrokes, but if you need a tag, it should be all tags, if you ask me.

One place where CFSCRIPT's functionality exceeds tags is in a loop over an array, where the array will be changing lengths during iteration. For example, an array of names, and you're supposed to remove all of the names that don't have an 'e' in them. You have to use a conditional loop with a separate index counter if you want to stick with tags, but with CFSCRIPT's for loop, you just do it as normal.

Sami Hoda wrote on 04/14/06 2:50 PM

Yup, its easier to read sometimes, especially when setting multiple vars, but has been left incomplete by Allaire/Macromedia.

I can't say I hate it, but "silly" does seem appropriate here.

One thing to note...

Look at some JSP 2.0:
<jsp:invoke fragment="Frag2" var="resultString" scope="request"/>

Look familiar? Me likes tag based coding :D...

Yacoubean wrote on 04/14/06 3:01 PM

Joe,

Your arguments against cfscript are the EXACT same things I say to myself when looking at all the MVC frameworks. The /only/ value I can see with them is that I'm using a coding methodology that /might/ be familiar to people that look at my code later. I can do all the same OO stuff that the _______ framework offers with pure CF.

Sorry, I had to get that off my mind, and you started it by attacking cfscript! ;) By the way, more on topic, I don't use cfscript either.

Dave Ross wrote on 04/14/06 3:20 PM

"The /only/ value I can see with them is that I'm using a coding methodology that /might/ be familiar to people that look at my code later. I can do all the same OO stuff that the _______ framework offers with pure CF"

IMO (since it's friday)... if you've written a homegrown controller layer that rivals the sophistication and ease of use of the three major players (MG/MII/FB) - then share it or shut up. You code in a silo - that's great. Just stay in there and don't try to tell everyone how good it smells.

Yacoubean wrote on 04/14/06 3:30 PM

Controller layer? No I don't have my own home grown controller layer, I just use standard OO principles and ColdFusion provided tools like CFCs.

I have read a few blog post from prominent ColdFusion 'celebrities' talking about how hard it can be to do simple maintenance tasks in frameworks. The reason I use ColdFusion is because it's an awesome RAD tool. From all of the reading I've done on frameworks, they offer excellent OO capabilities, but you lose the RAD benefits of ColdFusion. Most people's answer to that complaint is that it's easier to maintain a site written in _____ framework, but see my earlier statement for a response to that.

All that said, I DO want to use Model Glue for a future project, so that I can have a better leg to stand on for these arguments (and have better career potential). I suspect I'll really like it, but that doesn't mean I'll use it for every future project. Frameworks aren't always the best answer for every problem.

Tariq Ahmed wrote on 04/14/06 4:30 PM

What I loved about CF when I got into it back in the day (CF 3.5) was that it is so easy to read in its tag form, and that continues to be a big factor for me.

For some reason large chunks of cfscript seem to take more time to 'absorb' visually. And some of that has to do with the way DW/HomeSite/CF Studio color code things.


Though this seems cleaner:
<cfscript>
doSomething();
</cfcript>

Than:
<cfset doSomething()>

* when you're not interested in the return var.

jim collins wrote on 04/14/06 5:21 PM

1. I like doSomething(); a lot more than <cfset doSomething() />. I typically have a lot of cfscript in my init methods.

2. CFScript allows me to port over existing Java code with very few changes.

And this is coming from someone who also used to dislike cfscript and saw no point in in.

Claudia Hoag wrote on 04/14/06 6:23 PM

Are you nuts? CFScript is way easier to read than a bunch of "<" and ">" and cfsets and all.
I can use either, I don't care. When I first started using it, there was supposed to be performance improvement. But like Jared said, when there is a list of cfsets, CFScript is way easier to write and to read, so sometimes I still use it.

Greg Fuller wrote on 04/14/06 6:47 PM

I don't think it should be deprecated, I think it should be enhanced to be compatible with an ECMAScript like Actionscript 3. The restrictions on queries and such should be removed.

It seems possible as there are already several scripting languages for Java: BeanShell, Rhino, Groovy, etc.

Tags may be better when mixing logoc with html but you can't beat using a programming language. Imagine writing a Flex application with actionscript 3 and mxml on the client side and Coldfusion ECMAScript on the server side. One language for both.

I think it makes sense to use tags for declarative constructs (html, mxml), and a programming language for logic.

Just my 2 cents.

Chris Phillips wrote on 04/14/06 8:01 PM

I'm not a huge fan of cfscript. It makes me want to type things like "if( foo == undefined || foo == bar )".

On the other hand, pretty much anytime I'm going to write more than 2 cfset's in a row, I use cfscript. It's just so much easier to read the variable declarations without the extra markup.

And, because of my "more that 2 cfset's" rule, I guess I've been using it a lot more lately with Reactor...

John Farrar wrote on 04/15/06 1:27 PM

Each of us have soap boxes. Your rant is a bust! We use script where someone would have a bunch of consecutive CFSets and stuff like that. If you don't like it... don't use it. You don't need to. (Of course you could create a function library in practically eliminate the need for tags!)


1. CF Script isn't confusing. (New developers get it... only experienced tag developers get confused because it isn't thier style.) (and note: Have you been to Hell yet, my guess is it's not confusing or something you want to really understand? Food for thought.)

2. Got to CFLib and find out how to extend the functions to CFTag code if you need. :)

3. Who told you they were a hard core programmer because they use CFScript? Or for that matter are you a hard core programmer because you don't use it at all?

4. Because some people like the style even when others are rude about it. No need to put others down or the approach. I recently have heard alot of criticism of tag based languages which would include the new MS XAML. Our need to criticise different is as naive as those who thought people with different racial backgrouds were less of a people. How about a little tollerance.

(i.e. no need to condescending about CF Script buddy! LOL If someone likes it and it's clean code... blog on your favorite flower. It would be worth more.)

Scott Stroz wrote on 04/15/06 1:43 PM

John,

You disagree so vehemently, yet you took time out of your busy schedule to not only read, but comment on the article, sounds like good jounalism to me.

Good journalism should not only inform, but invite debate. Joe even admitted that he expected others to disagree.

BTW - If you get this passionate about <cfscript> (or rather, someone else's commentery on it), maybe its time to limit your caffeine intake. ;-)

Jared Rypka-Hauer wrote on 04/15/06 1:45 PM

John Farrar,

1) If it's my blog, I'll damned well say what I want (which this isn't, it's Joe's so he can damned well say what he damned well wants, damnit). So express your opinion, fine, but making demands on his content is out of line and I'd expect a higher level of though than that from you.

2) "Fight fire with fire" works for fire, but not for what you seem to think is condescension. Being condescending to someone you think is being condescending is, quite frankly, worse than the original offense and has compounded the problem. Therefore I reject your comments as unproductive and off-topic.

3) What's in your blog? Or are you a perpetual consumer and make no contribution to the blogosphere? Where is your blog? Why do you think it's ok to homilize on the value of Joe's blog when, I think, you have reaped mass benefit from this? Once again, I find your post offensive, self-righteous, and assine. In fact, I think it's safe to say you've made an ass of yourself here. Don't be an ass, John... nobody likes it.

Sorry, Joe... some fouls just need to be called, right then and there. Grrrr. People. Can't stand people. Must control Fist of Death...

Laterz!

(PS - that's a Dilbert reference, not a threat.)

Joe Rinehart wrote on 04/15/06 2:20 PM

John,

Anything labelled "Foaming Rant" probably isn't to be taken the most seriously. I've learned a few things from this post, like different recognitions of array lengths. Hopefully, others thought about something they haven't thought of for a while: why use CFScript? That's the point of the post.

However, I do take your comparison of me calling CFScript silly to racial intolerance seriously, and also find it insulting of real cultural issues that deserve real attention and, when necessary, anger.

>Our need to criticise...How about a little tollerance.

How about a little spell-check?

Rick Mason wrote on 04/15/06 2:42 PM

Jared,

John does have a blog located here:

http://www.sosensible.com/blog/client/index.cfm

Chuck Williams wrote on 04/16/06 1:22 AM

Quite a bunch here. My first foray into the realm of web-programmatic control was JavaScript. I have since branched into many others, including actionscript, and CFML. To me, cfscript is less typing, that's it. I never espoused its strength or efficiency in my many debates with fellow coders. I find this conversation to be the epitome, and essence of the debate.

That said, my $0.02:

I have found cfscript valuable, and lacking simultaneously. Like a 12mm wrench, or perhaps a wrench set with a few pieces missing. When The nut isn't stripped (like a crazy client request) I can get things done quickly, and effectively; especially with cflib.org at my fingertips. However, there are times when things are "missing", and most of the time I'm working in CFML, but there are certainly times when the script works. (am I on the fence, one may ask?) Well, yes, but I will make one statement, even though I like cfscript, and how concise it *can* be, I would be in favor of deprecation. For one thing, it is a little annoying being halfway through a 200 line path of script, and having to jump out because the command you need only exists in the "mother" language. For another thing, this would push some form of consistency onto the ColdFusion development community that would have a similar effect (in my mind) as filtered water to a body. The results of which may not be immediately apparent, but it will taste better (purified), and help the body (community) live a longer, healthier life.

ike wrote on 04/17/06 1:03 AM

Okay, you got me.

I'll put my neck out here again. :)

Yes, CFSCRIPT currently is kinda silly (good word choice, Joe). I was completely unaware that the debate about it was as heated as it was, or apparently that there seems to be a big move to deprecate it (which will need serious consideration - see below). To address individual points:

ECMA vs. CF operators: yeah, I'll admit it could seem daunting to some to remember the mix of CF operators with ECMA syntax. I've personally not had a problem with it -- yes, I've written != and seen the error :) but not very often. I'm not sure if I would have them implement a hybrid (which allowed both CF and ECMA operators -- yeah, I know, a lot of folks are gonna say "eeeewwwwwww") or deprecate the tag.

Array Loops: I somehow didn't follow what was being said here. I noticed Joe got it. Could somebody post a clarifying example?

Off topic comment about racism: yeah, I agree with Joe, I think it's a bit insensitive to the real issue of racism. I've drawn parallels to racism, but I don't recall ever doing it in a conversation about programming, primarily in conversations about politics and social order. If I have, somebody let me know and I'll apologize. :)

My own work: I used it quite a bit with CF5 to create functions. I still have a number of functions written in cfscript, and a critical few that currently can not be written with the cffunction tag (more below).

In some earlier versions of the onTap framework (and plugins) I did use quite a bit of cfscript.

It's actually an interesting sort of evolution, because I'd largely stopped using cfscript until I created the html library in the framework, at which point I started using heaping gobs of cfscript. :) And I realized later (before this thread tho) that this was one of the big reasons that a lot of people were put off by the framework as being horribly complex (so this is in support of the idea that it's confusing to read or can be).

Although -- to detract from the support for the confusing argument, I was using large blocks of cfscript to generate html, so a person looking at it would then need to read the documentation for the html library to understand how 50 lines of cfscript became a table with a form in it.

I later added an xhtml wrapper which converts a block of xhtml into the same constructs, using the same html library underneath. This lets me get the flexibility I was after with the library while maintaining much of the straightforwardness of xhtml, so for me this is a win-win solution. It does however mean that I've now stopped using those heaping hordes of cfscript again. :) And now am back to mostly not using it at all.

The 90-10 Rule: Isn't there a rule that says that any unpopular software will have only 10% of the features it needs? :P Personally I think Joe's numbers are a little skewed. Are those numbers from Tiobe Joe? :P

Though to be serious, the only things that I really find lacking in cfscript are cflock and potentially cfquery/cfqueryparam and cfstoredproc. File access is reasonably easy to write into cffunctions either in CFC's or generic libraries, so I don't see those as being huge issues. Same with cfflush and cfabort. The cflock and query tags are what I cite because these are items which can't easily be converted into cf-script, in spite of the fact that my SQL Abstraction layer obviates the need for cfquery tags. :P

Crude Example: Query = CreateObject("sql.select").init("mytable","columns").filter("x",x).execute();

So when using this abstraction layer, you shouldn't ever really need to break out of script to get a query, even without fully abstracting your domain model with DAO's and such.

The Problem: One of the big problems with deprecating cfscript is that they need to find some way of providing alternatives to a couple of things that can currently only be done with cfscript. I think there are a couple, although at the moment only one really springs to mind, but this one is very vital to a lot of my work (not just onTap, but several client projects plus my full-time job at SiteManageware). The issue is that the file location functions aren't robust enough. Currently the following two functions produce different results:

<cfscript>
function thisTemplate() {
return getCurrentTemplatePath();
}
</cfscript>

<cffunction name="thatTemplate">
<cfreturn getCurrentTemplatePath()>
</cffunction>

The cfscript version will return the template in which the function is called. The cffunction version will return the template in which the function is declared. Until they've resolved this discrepancy and provided a singular function that will always return the template in which the function is called, I know of a number of applications that can't eliminate cfscript.

It's more complicated than that also, because cfinclude tags inside a cffunction are relative to the template in which the function is declared, not the template in which the function is called, and so in order to generate a dynamic path for an include or a cfmodule tag within one of these functions, you need to know where the function is declared. So ultimately we need one function to perform each task.

I vote to make getCurrentTemplatePath() to return the calling template, and a new function such as getFunctionTemplatePath() or getDeclaredTemplatePath() to return the template in which the function is declared. This would resolve what I already see as a flaw in CF as it is currently since getCurrentTemplatePath() is inconsistent and this would make it consistent. But they have to able to provide both features.

Personally I'd also like to see a function for fetching the path to the calling template of a custom tag or an include (or to possibly add this information to getBaseTagData() in some way) although I don't know what those functions would be called. :P

For my specific purposes, just adding getRelativeTemplatePath(from,to) to the native language would solve my problems (and it would make a lot of sense because several people have created different implementations of it, just like cfdump and cfsavecontent had been pre-implemented several times), although I'd still like to see them add these other functions and make getCurrentTemplatePath() consistent.

Sam Farmer wrote on 04/17/06 11:12 AM

A couple of points:

1. I still find cfscript easier to read but due to its limitations I find it only really good for setting/getting and, thus, use it mostly in the controller layer.

2. <cfset doSomething()> is very awkard. A cfaction tag would be nice so it could become; <cfaction doSomething()>

3. I wonder at times if in a few years we'll be talking about custom tags, maybe even .cfm, files vs cfc's in the same way as this cfscript vs cf tag debate? The more and more I write cfc's the less I want to use custom tags for anything, including layout. Just a thought.

ike wrote on 04/17/06 12:18 PM

couple of corrections:

1) in my crude example, CreateObject("sql.select") should have been request.tapi.getObject("sql.select")

2) if the ColdFusion team implement a GetRelativePath() function (or my preference GetPathto() for clarity) the syntax would need to be GetPathTo(to [,from]) -- the point being that this function is mostly used for creating relative paths for includes and custom tags, so the from argument should default to whatever is appropriate for the current template, whether that's a cfc or a cfm. (Or just allowing absolute paths in cfinclude and cfmodule would also resolve this particular issue, although personally I'd like to have the extra flexibility of these functions built-in anyway.)

--

I'm not sure I grasp why people find <cfset doSomething()> to be awkward. I understand that it's a semantic of gramar and that, if you're examining english gramar, "cfaction doSomething" would seem to make more sense. But in examining a programming language which only imitates English gramar occasionally, I'm not sure it makes so much sense, unless you're wanting to turn CF into Ruby. :P Personally I'd rather keep CF from becoming so syntactically varried that there is no such thing as valid syntax. Which might seem contradictory after I just suggested allowing both ECMA and CF operators. :)

The CFM vs. CFC debate is already happening. There are already a group of people advocating basically eliminating any use of CFM templates. Personally I don't see the point. It seems to me, because they behave in different ways and are useful for different things, that it's arbitrarily limiting your set of available tools.

John Farrar wrote on 04/18/06 11:56 PM

Blog is sorta private. It's not like a living room chat with friends... it's more like a soapbox in the front yard. Understand your point. (Yet... when you start off with Foaming Rant... don't you expect a response to the foaming as well?)

Either way... seriously I have a question? Why do you need to have something against CFScript? Are you working with someones code or what is the issue? If you don't use it it's sort of like complaining that the neighbor drinks Pepsi when your a Coke man.

John Farrar wrote on 04/18/06 11:58 PM

I haven't found the spell checker button on this blog yet. (Did you miss that CFScript function... I cannot find it either!) Thanks for pointing that error out. If my name was Johnny rather than John perhaps that spelling error would be solved!

Steve Brownlee wrote on 04/21/06 4:19 PM

I personally don't use CFSCRIPT a whole lot, but there are times I put large chunks of simple CFML into CFSCRIPT simply because I find it much easier on the eye. Regardless of coding style, using CFML tags simply has more extraneous characters, and if I have 30 CFSETs in a row, it's simply more legible using CFSCRIPT.

Let's put our petty differences aside and look at the business end of CFSCRIPT. ColdFusion's strengths over the years has been a gentle learning curve, rapid development and ease of deployment. If the brains at Adobe want to start getting PHP, (ugh) Perl developers to br more interested in ColdFusion, it's time to fully support the language in CFSCRIPT format. Make it comfortable for them to switch.

Let's face it; prima donna developers absolutely LOVE to get on their high-horses and expound the virtues of their scripting language (even though they ALL do the same exact thing in the end).

If Adobe determines that it is a financially sound idea - which it may very well not be - they should eliminate that barrier of entry for learning CFML. Remember, it's not about morals, it's not about being considered light-weight or heavy-weight, but it is about how people use your product, plain and simple.

Remove all the barriers for people to switch and gain market dominance.

ike wrote on 04/21/06 7:41 PM

John
re: "Are you working with someones code or what is the issue?"

I believe Joe said that ... in the very first sentence of the entry. :)

Steve
re: removing barriers to entry -- I tend to agree with that philosophy, although admittedly not everyone shares it. :) And unfortunately it's kind of double-edged with regard to cfscript -- it's hard to say if making it feature complete will ultimately result in the developers of other ECMA-style scripting languages becoming encouraged to switch or if they'll just find other things to be put off by, meanwhile other folks who're more comfortable with tag-based syntax may be put off by largely script-driven applications without realizing that there is a complete alternative. I'm not saying it will be worse ultimately for CF's appeal in the market, but rather that the influence of a feature-complete cfscript implementation may be driven by more nebulous influences than these crude examples.

In retrospect, although I mentioned cfquery and cfqueryparam being current features that aren't easily encapsulated via cflock, I think cfqueryparam may represent an even larger issue with regard to making the cfscript implementation feature-complete. In spite of my efforts to create a common syntax for SQL tasks, I have a difficult time envisioning a script-based implementation of cfqueryparam that would work without having cfquery tags around it to provide context. Ultimately cfqueryparam turns the parameters into question-marks in the query which then become bind parameters in a JDBC method call (forgive my rusty understanding of how this stuff works under the hood), so CF's p-code compiler needs to understand the context in which the string is being created, and I just see that as being rather difficult to recreate with cf-script in a way that would be intuitive for programmers, whether they have an ECMA background or not. My own tools for solving this same problem aren't flexible enough to provide true ad-hoc sql capabilities in spite of the fact that they cover a majority (or all) of the sql tasks needed for most applications.

Hussein A.W. Grant wrote on 05/22/06 4:06 PM

Hello my fellow Coldfusion AlliesHello my fellow Coldfusion Comrades, this is my first post ever on this site. I am from the small island Barbados and have been working with CF ever since version 3.

On the issue of cfscript, I can tell you straight up; folks need to learn to evolve with the language. I notice threads here about cfsript helps folks type less code for multi-line variable/var setting etc. Please remember that we have a simple yet remarkable capability on all computer operating systems worldwide known as copy and paste. If I have ten (10) variables to create, I write this first, <cfset x = ?? /> and copy this ten (10) times, then add the appropriate definitions after. This is extremely inconsequential on the scale of real programming. Personally, cfscript makes no difference in my humble opinion when it comes to readability. I don?t read the <cfset?, I read the variable name defined. I probably see things differently to many.

One day we must face the fact that cfsript may one day become obsolete. I personally prefer to consign my energy, time and mind power into things like flex and actionscript as my presentation layer and leverage the power of Coldfusion?s incontestable speed for developing highly vigorous data driven backend solutions.

I too was a lover of cfscript, however it is very limited and defeats the purpose of getting things done properly and promptly. A tag based language like Coldfusion does have its many positives. I personally will leave the scripting for actionscript 3.0. Don?t need anymore confusion in my Coldfusion psyche. So there, I guess I?m with Mr. Joe Rinehart on this one. It is silly.
Heh heh :)

Fred Fortier wrote on 03/08/07 1:53 PM

No you are silly

Joe Rinehart wrote on 03/08/07 4:57 PM

I can't help it, I have to do it out of respect for the AM crew:

Your momma is silly.

Claudia wrote on 03/08/07 6:05 PM

Mr. Hussein A.W. Grant:
"It's good to be the King."

Hussein Grant wrote on 08/18/08 3:31 PM

OMG! I can't believe I wrote that! That is like the weirdest rant I've ever written. I don't even fully get it and I wrote it. LOL Too much coffee is not good. My wife did warn me.

I Still personally think that cfscript is a bit awkward. It would only settle good in my mind if the next Coldfusion release (9) supported full scripting, otherwise for now I avoid it.