Ugh. Not me. I can't stand CFScript. I wish it would die.

+1 for pure cfscript code. Tags are great, but script is smaller, lighter, more compact.

I wouldn't mind it, and I am a little excited about Bolt. Even though I use Eclipse/CFEclipse right now, I would welcome a CF-only implementation that was easier to use and maintain.

Script would be awesome!

My only "ugh" comes from script-based queries built from strings. At least this example code shows the script form of cfqueryparam. I'm having a hard enough time getting people to use that without opening up the possibility of falling back on bad practices picked up from ASP vbscript.

Not me.

I appreciate programming languages like flex, java, c# etc, but i bought/use CF so i dont have to write strict language OO code.

Guys, I added a survey to the blog entry. Please vote!

I'm curious as to how CFC hints would work within that. Would they, or are we back to basic commenting in our code?

And is that CF9 ORM code I'm seeing?

CF Script?!?! Why? I mean, CFquery was one of the selling points of the entire CFML language! Does Adobe Really want us to re-write stuff to look like asp/php?

ColdFusion has always been billed as Rapid Application Development. Why slow it down? How important is it that we look more like java?

It comes down to personal choice. The fact you can choose is good enough for me :-)

cfscript cornfuzes me. But if you have a choice then more power to us.

@Ray, I'm not sure if this matters, but I was able to complete your survey 3 times.

var q = new query();
q.setDatasource("cfartgallery");
q.setSQL("select * from art where mediaid = :mediaid:");
q.addParam....

Um, no thanks.

<cfquery name="q" datasource="cfartgallery">
SELECT *
FROM art
WHERE mediaid = #mediaid#
....
</cfquery>

I do enjoy scripting in OO (i.e. ActionScript), but for simple pieces of code - like a simple SELECT query (which should be a SP anyways), old school CF code is perfect - clean, elegant, simple. I'm sure I will use some scripting in the new CF, but definitely not 100%. Not even close.

@AW - You cheater. ;)

I didn't like CFScript until I got into a lot of client side Javascript. Now I like it and it's a much easier mental transition between front end and back end code!

cfscript is great! it is easy when you switch between cf and AS3 alot.

script-based CFCs would be most useful in combination with support for method overloading.

What I love about C# is using Visual Studio. With real-time compilation you have the ability to get intellisense on local variables, system methods, and your own custom object methods, properties, etc.

The whole point of Coldfusion is being able to write web apps fast, but when I have to write large-scale apps that need and benefit from code reusability, .Net wins out because of the editor. (I also prefer using cfscript for the ecma-style syntax)

If CF9 gives us proper intellisense features in the editor, this will go a long way toward building reusable code in CF.

As long as you have access to functions like cfhttp and cffile and other "tag only" functions I'd switch over for many purposes.

ColdFusion is both praised and criticized for the tag-based syntax. That is why people say that ColdFusion is not a "real" language.

I really like writing cfscript, and it allows for a more rigid syntax, which is great.

It's like the difference between Windows/Linux or SQL/MySQL. Linux is more strict, and when you program for it then you end up with much better code (at least in my opinion)

To the cfquery worriers, what if they did it up E4X-style so that you can embed queries like you always have?

var q = <cfquery>
SELECT *
FROM foo
WHERE (a = ?)
</cfquery>;
q.queryParam(1, 'a', 'VarChar');

P.S. - I answered this question in May 2007:

http://rickosborne.org/blog...

Wherein I said:

"
if Adobe came to me tomorrow and asked me the following question, what would I tell them?

We’re going to release a new product: the ColdFusion engine and capabilities (easy queries, easy App/Session/Client management, etc) but you can now code in server-side ActionScript/JavaScript/ECMAScript. You get all the fuzzy wonderfulness of ECMAScript 4, including variable typing, E4X, lots of literals, anonymous and first-class functions, etc. But, we’ve gone in and added bindings for every part of the infrastructure, so there’s nothing you can’t do in this new language. You’d be writing your CFM pages and CFCs in this new language instead of CFML. Interested?

Essentially, it’s cfscript on steroids, instead of the semi-afterthought that it is now.
"

Can I get commission on every sale, thanks to my proof of prior art?

(I kid, I'm a kidder. No, wait, not kidding. Yeah, I am. No.)

Rick:

As long as there is some sort of "heredoc" syntax (a generic form would make more sense than a special case for certain tags) to allow multi-line string collection, the query code they have above is fine. <cfsavecontent> is my #2 favorite tag, BTW. Creating large multi-line strings is a nightmare in languages with only simple concatenation.

But you did bring another question to my mind. I'm all for making cfscript capable of doing everything cftags can do, but let me ask this: Will cfscript be able to "embed" cftags? What's the script-equivalent of the <cfscript> tag itself? I tend to switch between the two methods, but I love the tags for things such as <cfquery> and <cfargument> because the tag/attribute representation seems more expressive. If I'm in the middle of a <cffunction> and hit a long string of variable manipulation, I'll switch to script. But if I start in script, or I'm working in code someone else wrote in script, will I be able to "opt out" and go back to tags for a section?

The worst thing that could happen with this is if people who code primarily in one method are thrown into code written the other way and suddenly feel like they need to learn a whole new language.

I will move 100% to script, tags annoy me after lots of Flex stuff.

I only wish thy addopted the same syntax as ActionScript, oh well perhaps version 10 enhancements.

But it would be good hook to get ActionScript Flash / Flex people to pick CF as the backend.

I have really mixed feelings about this. I feel like I've been jerked around by cfscript in the past. Way back in CF5 days, I rewrote a bunch of code to use cfscript, because it ran a lot faster. When we moved to CFMX, there was suddenly no performance advantage to cfscript, and because a lot of things couldn't be done in cfscript, I started converting some code back to tags. I started using CFEclipse, and I converted even more back to tags because then I got validation and code assist. Now, if cfscript supports more features, and Bolt has really good support for it, will I start converting my code back to cfscript? I don't know. I just want my code to be consistent and clean, and having two completely different syntaxes to do the same thing is on balance more of an impediment than a help.

5 lines of code instead of 1, seriously, isn't this why we chose CF in the first place? Anywho, should make the ASP guys feel right at home - I heard they get paid per ascii character.

+1 for Server-Side AS3 plz :)

+1 for Server-Side AS3 plz :)

@David: 5 to 1? Really? I would have had that query as

<cfquery stuff here>
select *
from art
where mediaid = <cfqueryparam ...>
</cfquery>

Looks awfully similar to me. Err, I mean in size of course, not syntax.

I am NOT in the camp that thinks CF _needs_ a 100% compatible script version to survive. But after working in Groovy the past few months, I am definitely IN the camp that will switch to script based CFCs if they are added to CF9. Once you go script, you don't go back. ;)

Hang on a sec now Ray - you conveniently spread the CFML based query over three lines, when it was one line in the script block. So, lets compare apples to apples - the SQL query evens out, and we are left with 3 lines to set up and execute the query, and thats not including the "q.setSQL" call itself, to the one for the cfquery, and the, are we even counting the tag closing? More structure than code, no?

Both could be written on one line, but of course, we wouldn't do that. We MAY do that more with the CFML version, because we have the luxury of being able to space the query any way we want - that is to say, with more complicated SQL (and I personally deal with some complicated stuff) I'll space it and comment in it for the sake of future maintenance.

My main point was that it introduces complexity - logical steps in the building up and executing of a SQL statement that CFML was made to overcome in the first place.

I'm sure the ASP/PHP/JAVA community will love it ;-)

Ok, even if the sql were all in one line, you still have, at minimum, 3 tags + the sql string. Compare that to 5 lines of script. Is it really that big of a difference then? Or I misreading you? Either way - I don't think one or two lines different is going to matter much. If you prefer script, use script.

And - I wouldn't say it is just ASP/PHP/Java folks. You also got Flex/Flash/AIR folks using scripting as well.

Again - I was definitely in the 'tags are fine' crowd - but after working a while in scripting only environments (Flex/Groovy), it's amazing how used you get to it.

I like the fact that this will make our editor much more intelligent. I'm assuming it will also enable intelli on the tags as well.

I see where they are going with this based on flex/AS3 Flex Builder experiences. You have your tags and you have your action script. People are comfortable with it, and it works. However, you can do one or the other or both.

So, it looks like Bolt and cfscript are taking a lot from Flex Builder. I do believe this is exactly what we asked for.

I'm just excited to see that Bolt is going to be an eclipse plugin... Bolt + FlexBuilder in the same IDE... I'm in heaven.

We can't ignore the fact that most of the structure in the tag based syntax is actually functional. For example, when you write datasource="xyz" in the cfquery tag, CF was calling the q.setDatasource("xyz") for you. Script-based syntax just makes all that explicit.

My only hesitation with going back to script-based syntax is that old temptation to start thinking about web sites like a programmer again. The revolutionary vision of CF was to help you design your site using the same thought process the visitor has. It led to much more interesting, innovative, and usable sites, IMHO.

The curse of wanting to be like everyone else is just getting your wish.

/ejt

Love the tag based cfquery implementation. When looking at queries that are 20-30 lines, and requiring different implementation for each database the application supports, the tag syntax makes for easier reading and writing to me.

I would not mind writing other parts of the CFC in script though.

I like the implementation of the cfqueryparam in script.

Makes a lot of sense to define the params outside the actual query.

1. It's much easier to see when you haven't queryparam-ed a variable
2. For those queries where you have to include the same queryparam many time, you just have the one definition, which you can refer to multiple times
3. Makes the query much easier to read.

"I only wish thy addopted the same syntax as ActionScript, oh well perhaps version 10 enhancements."

The reasons for CF always were a low entry barrier, ease of use and RAD. With ActionScript, you have none of these. It would make CFML just more complicated.

Use ActionScript or Java or what else, where it makes sense. But, if you turn CFML into a clone of another language, then what reason would there be not to use that other language instead of CFML? I really think this would do CF (and it's market share) more harm that it would do good.

@Chris your argument doesnt make sense,

Since they are already introducing a script format, why use a java syntax when they could use an ActionScript format, its just a barrier to ActionScript people and confusing if you go between CF & ActionScript a lot, like we do.

For example

public query function getData(mediaId) {

public function getData(mediaId):query {

Its not that different, but different enough to be annoying.

If they were clever, and we know they are, the will support both, this will please the java people and the ActionScript people

and, while were at it, can we call a component a class.

Im sick of explaing that a component is a class.

So they could easily support both

component
{

or

class
{

@Dale

You cannot achieve the simplicity of CFML with AS-based syntax. And CFML and it's simplicity has been one of ColdFusion's unique selling points.

I agree that it may be more convenient for some developers not to have to change the coding style between a Flex application and a CFC. But, that's just a personal preference.

I also agree that the tag based syntax is just an abstraction. If there was no need for these, then why is there something called MXML?

In the past we read things like "write a database query in CFML and in Java and compare the amount of code". CFML is designed to make things simple. No need for things like prepareStatement() and executeQuery().

These abstractions make it easier to write applications. If I do queryNew() + setDatasource + setSQL() + addParam() + execute(), that's five commands instead of one tag. And there goes the easy-factor that comes with CFML.

With the new syntax CF code will look just like Java code (or PHP, or ASP, or whatever). And if it's just the same, then why should someone choose ColdFusion over any other language? (I know that CF is more than just a language, but, the new developer making a choice might not know.)

And the advanced folks that write blog entries and examples and tutorials will use the new syntax, because it is possible. And that may very well raise the entry level barrier for new developers that depend on these things.

I know I would not have started with CF if it had been the same as with Java. The argument that caught me was "but it's so much easier with Cold Fusion" (spelling intended ;-))

It's almost the same as with the return types vs. "duck typing" discussion some time ago. CFML still is not a strong typed language and there is no need for CFML to be like AS.

Ugggghhh. Javascript and I have a very rocky relationship. I just can't stand the syntax. I suppose I'll have to get used to cfscript <i>grumble grumble</i>

@Lola: Why? Use what makes you the most productive. As I've said, I can see writing my CFCs in script. I would not, however, write my views in scripts.

This is the most exciting thing that I've seen all day.

cfawesome.

Hmm, looking at that code reminds me of a .NET class I took lasst year (using C#). I wasn't over the moon with that, give me tag any day ;-)

I'd love it! As it stands right now, whenever possible my functions start like this:

<cffunction ... >
<cfargument ...>
<cfscript>
...

If I can make it even cleaner I'd love to.

Whether you like script or not, not having a full blown script language has been a HUGE barrier to adoption for ColdFusion. It's one of the main topics non-cf developers use to deride the language even when they really don't know anything about it. Having this feature completely removes that barrier to adoption and I'm actually looking forward to using it for my cfcs.

You have to admit, cfqueryparam is an abomination when it comes to readable code. Having a bunch of angle bracket things in the middle of my well formatted sql drives me nuts.

I have a better idea if the issue is about more CF developers, make CF free.

I would love this, I spend a lot of my time writing code inside cfscript tags already. Also can't wait for bolt!

FYI, the stats so far:

344 votes.
213 (63%) for
131 (38%) against

This is a good thing. Writing a function with a dozen args shouldn’t take as much text as a small novella.

Well, it's the shorthand nature (which, admittedly, is the feature that makes cfscript work). I somehow seem to have a hard time mentally translating such code into a format that is more English-like. Such as the query example, with the query example, my mind grasps the cfquery version more quickly than the cfscript version.

I guess that's why javascript can be a struggle for me sometimes - I have to mentally translate these into a pseudocode that is more "English-like", and I have to avoid getting tripped up over those punctuation syntax.

That said, I can adjust. It'll just take me a little longer to find the bugs in cfscript code . . .

Two of ColdFusion's strengths are a.) you can do quick n' dirty projects cleanly, and b.) the tag-based scripting makes it easy to read.

That query looks an awful lot like VBScript for my tastes.

CFScript has its place, but it's not as easy to pick up for newbies. CF thrives on ease of use and rapid development.

if cfscript doesn't have a corresponding way of coding EVERY equivalent TAG, then this is totally worthless.

i think most people will agree that it's not the syntax of cfscript that they don't like, it's the fact that you couldn't do cfquery or cfsavecontent in cfscript. so you would have to do out of it when you needed to use these tags.

also from what i see in the screenshot writing a query in cfscript is WAY different then it's tag counterpart. they should have just implemented blocks into the language and this would have help keep at least the syntax of cfscript close to the tag based syntax.

totally awful in my opinion.

Yeah, I think you are mis-reading me Ray, when using CFML, the only real coding you are doing is the <cfquery> and <cfqueryparam> tags - I mean are we really going to call the </cfquery> a line of code? If you insist - I always thought it a structural thing (i.e., you don't have to think about coding it, it doesn't take variables and/or options, it just closes the tag)

But, ok, 3 vs 5 lines...times a complete application. 66% extra coding, are you saying that this is the one and only section of coding that will produce the extra "bloat" when it comes to script vs. CFML? Is there trade off? Is the scripting faster? Is it easier to debug? Does having MORE lines of code in an application reduce the law-of-averages chances of there being a typo or something out of place that cases QA problems? Or is it just there because the code monkeys are too snobby to use something that is easy to do? Is the "power" of a language/framework defined by how "cool" it is to CODE in, or how good a developer feels when they do something very complicated with lots of syntax that another developer has to fawn over to see "how'd you do that?"

Maybe it is, but that's not my bag, baby. But, hey, if it negates the "I don't like all those TAGS"/"Its not a script/procedural/blah blah language" arguments from the anti-CF crowd, then have at it. BUT, if you come into my team, scripting CF, you better damn well have an absolutely amazing reason to do so, because my applications are complex enough as it is, and using CFML allows us to concentrate on the business problems, not the coding problems.

Cheers,

Davo

Yes, I would call </cfquery> a line of code. If you have to use it, its part of the code. It isn't optional. It is as much as part of the syntax as anything in the screen shot above.

Also, you are picking on -one- aspect, the query. Notice how return types and access attributes are specified? That's _less_ code.

I'd be willing to bet we could go through and find some cases where you type less and some where you type more with tags versus script.

I think it is rather presumptuous of you to imply that those who want scripting enhanced are only doing it to be cool or snobby. Maybe they just _like_ it and are more productive? If you and your team are more productive with tags, then sure, stick to it. But don't assume it's just the ruby/cool/whatever crowd who will want/use this new support.

Again, using just myself as a personal example, I've found that scripting is _enhancing_ my workflow, not making it any more complex. I will definitely use this _where appropriate_ in my applications.

I don't know why everyone is getting caught up in "how many lines of code" this will save/add. We could all program in ASM if we wanted to type less.

I want to work faster, and more efficiently, and for my own personal experience, cfscript just doesn't cut it. Perhaps its personal taste, but I just find it easier to read the tags, and easier to teach new people the tag syntax vs cfscript. I REEAALLLY dislike the idea of forking the language. I can figure out cfscript but its slower, and it might as well be another language - Why not just use java as the backend if you really want to just cfscript - this is practically what we're getting now.

I know a lot of folks seem to want cfscript, and some of them are quite vocal! But I hope Adobe keeps in mind the rest of the community before shouting all aboard the CF Script train.

My biggest fear: Half of the open source CF apps released will be completely in cf script, and the other half in tags, confusing new people and making the modification of said programs that more difficult.

I think Jeff brings up a good point. For the more advanced user, this offers a good choice to writing their components and other lines of code. For someone looking to learn about CF, it could just be plain confusing seeing things done different ways.

Ray - you'll have to forgive me, I'm reading off the screenshot, so maybe you can clarify the "Notice how return types and access attributes are specified? That's _less_ code." part of your comment (my eyes are getting worse in my old age!).

When you say "I'd be willing to bet we could go through and find some cases where you type less and some where you type more with tags versus script." - could we? Hey, that would be great. In all of the scripting languages I've worked with (a little PHP, some Java and mostly ASP), I've never seen it, but maybe Adobe has found a way to do it.

I'll admit I'm being presumptuous - but that mostly comes from my experiences with those outside the CF world who sneer at the product and people who use it. They look down at a "tag" based syntax as being for the kids - let the grown-ups script. I know, I'm SOOO sensitive! :-)

I could go on for hours about these situations with other development platforms - I personally witnessed IT departments remove development platforms that end (business) users LOVED, but developers/managers didn't consider it a "real" programming language. That's just so you know, I'm not making these statements in a vacuum, they are decisions I've seen made, and arguments I've heard presented in real life over the years. None of them were valid arguments.

Of course, script should be used where necessary - but that wasn't the title of your question. You used the "all" keyword, a blanket statement, and thats what I, personally, was replying to.

It's an interesting debate though, and I'm sure if anyone can bring me around it's the Jedi himself ;-)

Cheers,

Davo

(p.s., yeah, that last part was a big expectations set up on my part, muhahahaha)

@Jeff, Kumar: Why do you assume new people to CF will be confused by script? Maybe they used other scripting languages before? I will say though that if they have 0 programming experience, tagging will certainly be simpler for them, but I don't think it is fair to say that -everyone- new to CF will find script more difficult than tags.

My biggest gripe is having to use cfargument in CFC's. I don't know if it is going to be all or nothing with the cfscript cfc's. Mix and match would be awesome. I don't know how may times I wish I could write a plain old C type function in a CFC like you can in UDF's. Writing out name= type= default= required= etc. gets old REALLY fast, especially when you have a whole bunch of args.

I for one welcome our CFScript overlords.

@David: See how he declares the function?
public query function getData(...) public is the access and query is the return type.

"Of course, script should be used where necessary - but that wasn't the title of your question. You used the "all" keyword, a blanket statement, and thats what I, personally, was replying to."

Well, I said all _CFCs_, not all CFML. Again, I can see using scripting for the model layer (which is normally all CFC) and tags for the view layer (which is normally all CFMs).

As for bringing you around... all I can suggest is trying it. When you can of course. ;)

+1 to Jeff and Kumar.

There is little question that cfscript syntax is more difficult to follow for newbies.

While it seems silly to say Adobe should _not_ do this (having options is great, to each his own, etc.) I can definitely see how this could have a negative impact as well.

Adobe does a pretty poor job of promoting this product, which means much of that burden falls on the shoulders of this community. When newcomers - or just plain entry-level to intermediate CFML developers - search out to find out how to do things, they will be seeing a hodge-podge of code examples with less uniformity than before. I suspect that this will confuse and discourage a large group of these developers.

I guess the balancing act is how much writing CFML in script, or script+tags, enhances the productivity of some in this community versus how much in confuses an alienates others in this community?

OK, I see what you're saying now Ray, and I think it does re-affirm the point you are trying to make on "lines of code". It's where you make them that counts more, right? You're more likely to have more queries in an application than you are functions, in general, but you may make up for that in other ways.

Still, I'm waiting for the compelling reason to use script, other than "I can" (I script, therefore I am???). If there were performance gains by using script, now THAT would get my attention. Whether it be ALL applications, or ALL CFC's, I'm still looking for that reason.

As for trying it, I'm sure I will, as will my minions! If they present a compelling reason to use script, then we'll definitely go with it, and hey, you never know, I may be back on your blog scolding you for not using script enough!

Cheers,

Davo

looking at the code doesnt mediaid have to be declared first before you use it?

It is - it is in the argument list.

If you look at the toolbar just above the component start...tag.. there's a <> button and something next to it that appears selected. My thinking is you can switch modes within bolt! E.G. code in script if you want but then switch but it still gets saved as tags. Even if that's not the case, it would be pretty damn cool!!

In my over excited state i messed up part of that comment. you get the idea though

@ray i thought you would have to do something like this before the query code:

public var mediaid

You don't var scope arguments.

@chad

mediaId is the input, like <cfargument>

A friend just told me in c# you can add an @ in front of the opening quote for multiline syntax.

q.getSQL(@"
SELECT *
FROM table
WHERE ID = 2");

That would make the SQL a lot more readable. Hopefully the CF guys will think of doing this.

You can do that right now in CF:

s = "
This is a multiline
string in CF. CF ROXOR
"

The only thing you have to watch out for is escaping your quotes, but SQL shouldn't have quotes in it anyway. ;)

@Ray, I am not saying that seeing cfscript will confuse people who are new to web development or people who are looking to learn CF.

I am saying is that, come CF9, online blogs, tutorials, articles, will now have the same thing done two different ways. Which in some ways, could prove confusing for someone looking to get into CF.

I'm all for it. I wonder if we'll be able to pass parameters to initialize the query.

var q = new query(dsn="cfartgallery");

That'll save you one line right there :) Or you could pass an entire argument collection and be done with it.

Just to reiterate on my last comment, as I've realized it made no sense - my thoughts are that this feature could not be CF9 specific, but a new way of viewing (and writing) code in Bolt. I guess an analogy can be drawn to the design/code view in dreamweaver, except this is tag/script view. This would make sense, as you could switch to tag view to type queries and to script for functions (which I agree would be SO much faster). The whole thing could then be saved as a tag-based CFC, thus eliminating the confusion to non-scripters when they come to view the document.

My thought on this came from the <> button in the toolbar, suggesting tag view. I could be wrong, but this would seem like a great way of allowing scripting in ColdFusion.

If people like scripting so much... start writing your applications in JSP ore pure java. Coldfusion is tag-based.. and I hope will always stay that way otherwise I see no difference between PHP, ASP or Coldfusion.

So stop asking for scripting support in a tag-based language, or start using a scripting based language and quit Coldfusion if that's the major thing your missing in the language.

@Tjarko: Have you every written a view type page in JSP? It isn't nice. I don't think anyone is asking to make CFML 100% script based. As I said - I think 100% script will make perfect sense in the model, not the view. Much like how Flex does it. Don't knock it till you try it. ;)

Poll stats:

491 entries.
Yes (300 or 61%)
No (191 or 39%)

please give me cfscript or i will kill myself. Can't stand this cfml-crap. Give me something that resembles programming.

Nice comment there. I have absolutely no respect for someone who attacks behind a fake name. Pitiful. When you grow up and stand behind your statements, let me know.

@Tjarko

ASP.NET has tags and PHP is commonly used in a tag like manner in the presentation layer (Joomla templates for instance). Maybe it is not binary and the two can co-exist and used where it makes sense. Tags in the presentation layer and script in the model. You know, "two great tastes that taste great together"? Options are good and could lead to a *gasp* broader audience for CF.

Besides ppl are going to have to learn JS sooner or later and CFscript can provide a great lead in for JS.

@TJarko....having options is great, and I assume the CF team did their homework when they decided to make this an upcoming feature. Given the response to the poll, it would appear that many CFers want to script their CFC's (Ray's blog pretty much has the ear of the community, so I'd say its pretty scientific).

Whether you use script or tags, CF still has a powerful engine behind it that you just don't get with JSP. The language is just the interface to the engine, be it tags or script.

Cheers,

Davo

It won't be 100% but it might be a high percentage.

If you could go ahead and just make CFSCRIPT not weak, that'd be greeeeeaaaat.

I use a bit of CFscript, but the majority of everything I do is in CFML. In my opinion, the fact that I can develop powerful web applications using mostly tags, is the biggest selling point of ColdFusion.
I've never been a fan of the script syntax, so CF has literally been a godsend.

I'd do it just for the hell of it

I've been a CFScript fan since it first came out. The more I can use it the better!!

Hey Rey! How about displaying the results of your poll? Or am I missing that somewhere?

WilGeno

@Will - I've posted it a few times. I'll do so again tomorrow.

wow. why all the fuss? CF is dead anyway :)

no but seriously... why all the fuss? it's not like <cfcomponent> and <cffunction> and <cfargument> are going to stop working.

if you like script-based syntax, you can write your CFCs in script now. if you don't... nothing changes. all this does is add the option. more options are "a good thing", right?

Honestly, I really feel like everyone who is being negative is maybe just a little shell shocked. Honestly, this type of situation works fine in Flex Builder and Flex Builder is nearly a perfect IDE.

For people that have moved onto breaking their code into model/view/conroller, they will probably understand script enough that an open source project in tags or script will be easily understood. This is the qualm, right? Open source and existing projects splitting into model code based on 100% tags or 100% script ?

Yeah... What Charlie said.

Huh... I think that I will port one of my apps and write the front end in all CFScript and do the model using just tags. And then post it to RIAForge. You know, just for the WTF factor.

All ? Nah... I'll hardly ever 'always' do anything. There may be some benefits, and for complex CFCs it may even be clear.

I think the importance of this feature, from a strategic point of view, surrounds the placement of ColdFusion in relation to Flex and AIR. Both have taken off and are rapidly filling a void in their respective application spaces, and its not JUST CF developers who are using each (Flex for example, has been largely targeted at Java developers, for example.

I get the opinion, that CFML is to "script-coders", as the Flash "timeline" was to developers in general. So, would having the option to code "All" (or any) CFC's in script appeal more to Flex developers? I'd imagine so. It certainly wouldn't be to the detriment, that's for sure.

If that is the case (and I'm assuming Adobe did their homework on this), it would place CF closer to Flex and AIR, and present it as the best product to use as a back end for these applications.

That could seriously grow the user base for CF, especially if CF9 has tighter Flex/AIR integration (I can only speculate it will). I think most of us would agree that an increasing significance in CF in the marketplace is good for all of us.

Just MHO.

Davo

It's a little disappointing that this has devolved into a quasi-religious argument. In my opinion it's not an either/or supposition.
In our development I could see a use for scripted business logic components and cftag'd DAO components.
ie.
resultSet = daocomponent.getResultSet(arg1,arg2);
(where daocomponent uses <cfquery> tags)

I was fairly ambivalent about the whole BOLT/cfscript news. Until I realised that with a scripted approach there is much greater scope for code-time introspection+validation (ala Flex Builder). This can only improve the coldfusion coding experience.

This is pretty late in the game but, I'd rather see them focus on features than implementing a new way of coding the same old stuff. I just don't get it, why do you need 4 ways to code CF? why not make it do more?

I also don't get why everyone is so gaga about an editor... I like textmate, works fine.

on a UI note, ray you might want to highlight the error fields on these forms, took me like 3 times to realize I didn't enter "http://" into my website.

@Steve Ross
..and notepad, works fine.

But I get gaga about developing Java in IntelliJ and ActionScript in Flex Builder because it increases the speed and accuracy of my development.

Rich, Intelligent IDE's exist for a reason and I don't think it helps the discussion to say the equivalent of:
CD's? why bother? Cassette Tapes work fine.

@SteveRoss - I'm working w/ someone on a new skin in the next month or so and I'll make sure that is covered.

I'll post new survey stats tomorrow.

I don't know if I'll write many CFCs in cfScript yet. Like Ray mentioned, I think a lot of things will play out marginally faster than using tag syntax and others marginally slower.

One thing's for sure: I absolutely loathe that query syntax (the screenshot). It seems totally backwards from where I'm standing. Even the concept of being able to instantiate a "query" object before executing its sql feels counter-productive and dim. It feels like jogging in place. It's completely reverse from the tag approach, prepare all of your arguments/attributes, hell, put them into a single collection if you're incredible, and then go. Trigger the functionality. Don't author the tag, fiddle with and change it, and then trigger its real purpose with even more typing. That's nutty.

I wish it looked like this instead:

var cfQPs = {

id : { value: arguments.id, type: 'int' },
firstName : { value: arguments.firstName, type: 'varchar' }

};

var sql = "
select *
from table
where id = { id }
and firstName = { firstName }
";

return cfquery( sql: sql, params: cfQPs );

Notice I am NOT instantiating a query object, ever. There is absolutely no reason to. I'm calling a global method that does what it should, parallels cfquery, probably the most valuable tag ColdFusion has.

<cfquote source="Davo" >
...it would place CF closer to Flex and AIR, and present it as the best product to use as a back end for these applications.
</cfquote>

Disagree, ColdFusion has ALWAYS been presented (and even acknowledged by competing communities) as the best, most-integrated, go to backend for EVERY Macromedia/Adobe client technology. I don't think richer scripting support will have any bearing on that.

<cfquote source="Davo" >
That could seriously grow the user base for CF, especially if CF9 has tighter Flex/AIR integration (I can only speculate it will).
</cfquote>

People don't switch languages/platforms/insurance providers/video game consoles just to be able to parallel their previous experiences (script syntax). They do it because of some frill, productivity gains, economic benefit, reputation, sex appeal, or improved experience. Call me a prophet, but better script support won't convert ANY people to ColdFusion. If anything, the "not a real language" peddlers will change their tune to "so you've finally caught up to 1998" roasting. If anything is going to get ColdFusion adopted it's 1. Exposure and 2. the redux of significant, measurable development and maintenance reduction as the number one selling point. Why else use ColdFusion? It's faster to write. More similar to other languages, in ColdFusion's case isn't a boon, it's a de-individualizer. The more ColdFusion simulates and bends its knees towards other languages, the less differentiating it appears.

David, I'm not sure we're in disagreement, so let me qualify my comments. First of all, I'm in total agreement with you - adding script support is not going to change the attitudes of the "anti-cf" crowd. They are a lost cause. Even when presented with all the evidence, and the business propositions of a quicker, more efficient way to develop web based applications, they scorn at it and stick to their comfort zone. That's ok by me - some of them are my competitors :-)

What it DOES do, is allow Adobe to present a solution to development shops, which is tight knit integration of Flex, AIR and CF. The only thing that scripting adds to that proposition is its familiarity to <insert scripting technology> shops when they are presented with code samples. If development shops are adopting Flex/AIR as their development platform, then positioning CF as a logical inclusion can ONLY grow the development base (IMO).

I kind of agree with you on the "de-individualizer" comment, however, I don't thing being a tag based syntax is CF distinguishing feature. It's all of the bells and whistles that come with it - the PDF creation, AJAX features, SOAP, Exchange, .Net, etc etc integration (I don't have to evangelize here, you know what I mean), and how easy it is to do all of that compared to other languages and frameworks.

Cheers,

Davo

Survey Update:

Total results: 629
Yes: 391 (62%)
No: 238 (38%)
TGIF: 629 (100%)

With this supposedly new feature coming, how come I haven't seen one book on Amazon about OOP in ColdFusion? Strictly and directly dealing with OOP?

The book market is pretty bad now. There are 4 CF books out now (3 wack, and John Farrar's book), but I'm not surprised there isn't more.

Voted 'yes', despite fact I love CFML, use it everyday since 2002 and think CFML is what does CF great. Voted because I impressed by Flex approach - use MXML for describing interface and ActionScript for implementing logic. In the same time you may use both vise-versa if you like to. I feel such dichotomy will work great in CF as in Flex, something like:

<cftable dataProvider="#obj.getData()#">

or even... <cf:table> ? But in same time obj component will be described in external CFScript file as written above.

For me pesonally, implementing logic with CFScript looks faster and cleaner than with CFML. I think CFScript should become more what ActionScript is for Flex.

BTW: Bunch of people I work with came to Coldfusion coding from scripting world and CFScript was their bridge from PHP/Perl/Python to Coldfusion.

@Rodion: As just an FYI, are you aware there actually is a cftable tag in CF? :)

It's interesting to see what an inferiority complex we CF developers have, as evidenced by the argument that, with more cfscript support, others won't look down on CF as not being a "real" language. I can honestly say that 95% of the reason I chose CFML over PHP when I started my business was strictly for the syntax. For me, CFML is RAD because I have a MUCH easier time understanding and writing tags than script. Go ahead and tell me I'm not a "real programmer" because if you don't use CF yourself, I don't give a f--- what you think! It's kind of ironic how right around the time Adam Lehman blogged about how we shouldn't be looking at other languages and that CF should strive to innovate and stand out, here we have everyone looking jealously at Java and AS and worrying about what others think.
As a side note, while I think it's a good idea for Adobe to promote CF as the ideal backend for Flex apps, from some of the comments here, it appears that there are those who feel that CF is ONLY good as a Flex backend -- WTF?
Yes, yes -- I realize that I would still have the choice to not use cfscript, but my concern would be that CFML would develop an identity crisis and further fragmentation is the last thing a community as small as the CF community needs. A previous poster commented how in the future, open source CF projects might start using more and more script in their model code and it gave me flasbacks of my days trying to wade through OS PHP code -- yuck! I also don't relish the prospect of the CFscripters telling those like me in a few years that my code is stuck in 2008.
Anyway -- maybe it's me with the inferiority complex. I totally get that everyone has a right to their opinions and their coding preferences and that it's good that Adobe is listening to the call for more cfcript support. But the bottom line is that -- for me, personally -- it's depressing as hell to see that most CF developers (according to Ray's poll) are pretty much saying that they're unhappy with the syntax they're coding in and it bodes a shift in the language away from what made it such a huge selling point for me.

2Raymond: actually, I am :-)

What I was thinking of (and may not express well with my one-legged English) is that CFML and CFScript should be interchangeable as MXML and ActionScript are in Flex. That will give freedom to developers and silence those telling 'Coldfusion is not serious technology because of its taggish language and lousy OO model, blablabla'.

After getting to know Flex I started to adopt it's approach in Coldfusion - I use CFML tags for describing interface and CFScript for implementing logic. Even for queries - we used to create homebrewn ORM implementation in our team and not using <cfquery> tag anymore. Probably, some will say it's much handier to use <cfquery> and not to wiggle with CreateObject...

@Rodion

>> After getting to know Flex I started to adopt it's approach in Coldfusion - I use CFML tags for describing interface and CFScript for implementing logic.

That is exactly how I feel. The more time I spend writing JS and Java the more want to forgo CF tags when writing logic and functions. Tags are ideal when dealing with XHTML. But when writing functions in a CFC, tags get to be a bit much. I spent a year writing PHP and I really missed the simplicity of using cf tags. Escaping quotes and concatenation gets old very fast. But at the same time writing a paragraph of text in order to pass in variables to a function with a dozen args is overkill too.

As far as the simplicity of tags, and reducing the learning curve, having inspection and autosuggest for external libraries and local vars, a la Bolt, will make it much easier for noobs to get the hang of using CFScript.

Sounds like Adobe is turning CF into a gateway language for Java.

CF has been 'intimate' with Java for a while. In the end it's all about supporting the style you want to write in.

CF is definitely a gateway drug. It is very addicting and leads to all sorts of fun stuff like Java, Groovy, jQuery... etc. and has built in support for Flex, Spry, Hibernate ... etc. etc. Definitely my DOC.

Ur sirvey is broked. tak it doun!

I know, I know. :)