The point is: nobody wants to learn more languages then nessecary.

adobe has the opportunity to bring the the designers and programmers closer with using Actionscript3 in Coldfusion. Heck, i hate the var != {":'''myboolean"">"} kind of programming (it reads like a curse) but when it is needed, learning Actionscript has the great advantage of also being able to program some Flashlite apps and whatnot (i did some animation with Flash 3.0, those where the days.

In the end, it's all about productivity, both for programmers and for business/clients. Nobody gets more productive needing to learn / know extra (half-baked or not) languages, standardization is king when it comes to productivity, even if that standard has some flaws or weak points.

Well, just my 3 cents.

Theirs nothing wrong with being able to write a whole program is cfscript (why not) as long as it dosent make coldfsuion server run slower its a good thing. We still have all the basic tags in thier simplicity, and if you want to mess around with cfscript then its an option. Adobe are forward thinkers, thier heads are ten + years from now. Cfscript can make very light weight apps, for mobile devices.

This is long, sorry.

My take on things is that the ColdFusion started of as a tool for adding a bit of dynamicism to websites, and reducing the number of .html files needed. If one has 100 .html files (eg: product pages) all with the same layout and just with different detail, then the detail could be abstracted out into a DB, and replaced with some CFML to fetch and display the content. And a nice way of doing this was to intermingle the HTML and CFML in the one file: it's reasonably clear what's going on, and the relationship between the static HTML and the stuff made dynamic by the CFML. Tags are a sitter for this because they look unobtrusive sitting next to the HTML mark-up, can "wrap" regions of mark-up to process them somehow (like a loop), as well as a tag type construct is easy for a parser to pick out and process (the parse looks for <cf...> and knows that's an instruction for it).

This is where CF arose from. We all know this.

And if the remit and usage of CF remain "make my website a bit dynamic", then there'd be no reason to ever use anything other than tags. They would be the best fit.

However websites got more complicated and bigger, and their processing requirements got too complicated for a bunch of .cfm pages which basically populate a layout. Using that sort of approach quickly became unmanageable, with similar-but-not-identical queries repeated all over the shop, business logic mixed in amongst presentation logic, and bits and pieces of everything being duplicated everywhere.

Before too long people realised that this was a crap way of developing websites (other than really small ones), so we saw the rise of a multi-tiered approach to things: DB interaction, business logic, application control and presentation files being separated out into different tiers: MVC.

So we've still got the equivalent of the old "CFML mixed up with HTML" files around: these are the presentation files. The views. Tags abound. Perfect.

However we've also got tiers of files for DB abstraction, business logic and application control in there. With nary a line of HTML to be seen. Suddenly the "good sense" of the tag-based language didn't really have a good sensible basis. What's the point of the "it's just like HTML" if there's no HTML around? It's a complete myth that CFML is easy to develop in because it looks like HTML, and everyone here knows it. The similarity between HTML and CFML is superficial.

A later twist to this is that as the web matured, suddenly the requirement ceased just being "web sites", but started being "web applications". This pushed further back the "work horse" code from the view tier of things. I guess the views too got more complex, but so did the business and application logic requirements. So in these situations, the proportion of code that ever gets anywhere near HTML is reduced further.

Still. CFML does the trick. One can do <cfcomponent> and <cffunction> and <cfstoredproc> and all that sort of stuff. But for a lot of people, there was the question "why am I doing this in TAGS? It makes little sense". A lot of people aren't bothered by that, and indeed this would not occur to even more people (and the bulk of people are still just sticking all their view/control/business/DB logic into the same template anyhow!)

However there are a lot of people that do question the sense of being tag-bound in an environment in which tags make no sense, and would rather get their code written in a more expedient, readable and "fit for purpose" kind of coding style; ie: all that curly bracket and semi-colon nonsense we know as CFScript. This applies especially to people who come from other languages where script-styled syntax is easier to read, whereas tags have them going "WTF is all this?" at first glance.

I think there are two schools of thought here: 1) CFML is all about tags. Script isn't tags, therefore it has no place. 2) CFML tags are a good solution to some situations. However outside those situations, script seems better because it gets on with the job, and is less cluttered so is easier to eyeball because as one reduces the clutter, the stuff one wants to look at stands out better.

I think the first school is probably mostly populated by people in these categories (some or all): - started out programming in CF - possibly from another line of work within the IT industry other than programming - spent a lot of time on smaller projects before migrating to larger ones (if they ever did) - think "website" rather than "web app". - aren't so good with "change" or diversity

I think the second group is probably populated by people in some of these categories - came to CF after having experience in another language - not necessarily a web-oriented one - were dedicated programmers before starting with CF - have spent a lot of time working on larger apps - possibly create the applications that build the web sites, rather than the websites themselves, so possibly don't work with HTML that much - don't get freaked by seeing unfamiliar stuff (not that it would be unfamilair) - and pause for thought as to what the uses of it might be

(these are generalisations, so I know will not apply to 100% of people, or apply 100% to people)

This means there's a bunch of people for whom tags have a certain place, and are a great solution for that requirement. However they're not the be-all and end-all of a language, and CFScript is a better tool for the job in a lot of situations. The historical problem here is that a lot of CFML functionality is only presented in a tag implementation, so even in situations better suited to script-style syntax, one still needed to drop down to tags fairly frequently, simply to accommodate the fact that some functionality had only ever been implemented as tag. This makes for bloody ugly code, eh? This got less and less once CFCs came in, though (wrap the <cfquery> tags, and the like in CFC methods, and call the method from script).

Looking away from CF for a moment, I've done hardly any Flex, but talking to the Flex developers I know, they use MXML tags for laying out their views, but all the inner-workings are done in ActionScript. There's no particular marriage to tags there. They just use the best tool for the job.

Adobe seemed to have picked up that doing tag-only implementations of some things is restrictive, and sometimes makes little sense anyhow, when they could be more easily and more flexibly implemented as a function (or service, as we're seeing in CF9), which can be called equally from tag code and script code.

Not that there's a function version of <cfdbinfo> yet, but this is a prime example that's had me going "why is that a tag?". It is a bit of functionality which takes some parameters and returns a value. Sounds like a function to me:

<cfset myDbStuff = dbInfo("myDsn", "tables")>

Even where there's stuff that doesn't return a value, they're often still "a bit of functionality which takes some parameters and does something". It's still a function: it's not a tag.

There are certainly a lot of CFML constructs that make no sense being implemented any way other than as tags though. All the <cfform> stuff, <cfdocument> and its bits and pieces... better as tags.

There are other situations in which having both tag and function-approach have benefits. Using <cfquery> to wrap up a bunch of conditional logic which builds the SQL string is nice. But if that's not necessary, this is nice too:

<cfset myQuery = new Query("myDsn", "select * from table where something=somethingelse").execute()>

Most of my queries will be done via Hibernate now, but the rest of them would be a 50/50 split as to whether <cfquery> or the new approach will be the most expedient. But I reckon the split is most likely going to be 80/10/10 in favour of Hibernate doing it for me.

My point is that if something makes sense as a tag: do it as a tag. If it doesn't make sense as a tag: don't implement it as one. I think the test here is that if whatever functionality is being implemented might make use of a both an opening tag and a closing tag: make it a tag. Otherwise don't, because it's not appropriate to be implemented that way. Unfortunately Abode, Macromedia and Allaire got too hung up on "implement everything as a tag whether it makes good sense or not", which lead to a lot of functionality only being tag-based, and unusable in script. Adobe is playing catch-up with CF9. This is basically work that should have been being done all along.

Bear in mind there is already an awful lot of functionality in CFML that is not tag-based (370-odd functions compared to 140-odd tags). It's not like any sort of precedent is being broken here by implementing stuff that isn't surrounded in <cf>.

Some people say "well if you want to do all that curly bracket stuff, why don't you go do Java". This is just demonstrating ignorance. Ignorance about how programming languages work, as well as ignorance as to what makes CF a great language. The difference between script and tag-based code is just the control structures (if() vs <cfif> etc), and - currently - a few bits of functionality that are not achievable in script. I dunno why anyone has a strong opinion for or against angle brackets or curly brackets, which is the chief difference between the two coding styles. Bear in mind that - other than a few control structures like "throw" and "finally" - most of the new stuff being touted as being for CFScript will work equally well via tags, as per my example with the Query service, above.

The thing that makes CFM a great language isn't the shape of the brackets it uses: it's that if one wants to write a file, one just uses <cffile> or fileWrite(). No arsing about with IO streams and buffers and that sort of thing, just write the file. Want to query the DB? No need to bugger about with connection objects or arrays of prepared statements or that sort of nonsense... just run the query. or the <cfquery>. I have *no* *idea* how to make an LDAP connection with Java. In CFML we don't need to know, we just need to use <cfldap>. It doesn't matter if it's <cfset myLdap = new Ldap(things here)> or <cfldap things here>. Want to do a Flash form? Well use the <cfform> tags. Doing that via function calls would just be dumb (and that's one bit of functionality implemented as tags tha is a good example of what should be left as tags). The tags are the best approach to the job here, and the functionality iself is very bloody powerful, innit?

The *good* thing about CFML is that all the inner workings are done for us. It's not about what sort of bracket we use. Like I said: that position is just ignorant.

Anyone who has a hang-up either way about whether they like {} or <> is a baboon in my books. Just get over yourselves, and use the best coding style for the task at hand (or your preference), and use the best tool for the job. And the best tool is CF.

Cheers for sticking with me :-)

-- Adam

Like Alan, I absolutely abhor cfscript, and for the most part, its outright banned on any projects I am in charge of. I can't think of any other languages that have two version of syntax, I personally think its silly and superfluous, and I wish it would die.

However, as Ben and Adam pointed out, and as I suspected, I think this was a case of Adobe simple responding to the demands of its customers, and I can hardly blame them for that.

Although part of me would have loved to have seen them say, "we're killing this, no more cfscript", that would have upset a lot of people, who would have screamed bloody murder they way I might if they killed of a feature I loved.

I hope that popular frameworks and open source projects avoid cfscript completely. It will make it that much more difficult for beginners who will have to learn TWO syntaxes up front.

while i will admit i HATE CFSCRIPT, it's because of the differences between CFML and CFSCRIPT that make it so and i'm just talking about the whole tag thing either. case in point: using cfml you can loop over an array with <cfloop array="">, however this isn't possible in cfscript. as much as i like the whole idea of giving people choices, i want equality between the two syntaxes to finally be complete. plus i don't like the whole idea that you have <cfdump> in cfml and writedump() in cfscript. why couldn't they just have named the functions the same as the tags? what's wrong with using <cfdump> in cfml and cfdump() in cfscript?

I use CFSCRIPT whenever I have a long string of math to do, or if I'm populating a structure with a long list of interpolated values. It's handy for me since I'm writing less code, and handy for whoever looks at it, since it's much easier to read in some cases.

As for making CFSCRIPT handle everything - why not? If I have chosen to use CFSCRIPT for a block of code, I hate having to close tags and reopen them after a "tag-only" operation is required.

I do get what you're saying, and I agree to a point, but the bottom line is that it's difficult to justify "not" doing this, since it doesn't really hurt anyone.

Like Ben, I'm not a big fan of cfscript either. In fact, I called for deprecating cfscript in CF 7:

http://www.brooks-bilson.com/blogs/rob/index.cfm/2004/5/12/104

And again in cf 8:

http://www.brooks-bilson.com/blogs/rob/index.cfm/2006/8/1/My-Scorpio-ColdFusion-8-Wishlist

That said, what the committee is focusing on is ensuring (through the CFML2009 spec) that the language design around the full cfscript implementation is done in a consistent and thoughtful manner.

Hi Allan,

Everyone is entitled to an opinion, and they are often like assh*les, most of them stink. I have never really seen the point in CFSCRIPT for the reason you say, it is not CFML, I use CFML because I like the tag based-ness of the language which makes it easy to read and understand. However saying that, I have found occasions where it came in useful when I have had to write a complex function and it has simply turned out to be easier, shorter and more readable in cfscript as I know Javascript. So I certainly do not think there in any harm in CFSCRIPT existing, and it is as much someones choice to use CFSCRIPT as it it is their choice to code CFML precedurally using just tags, functions and includes or to go down the OO route and use CFC's et al. Yes clearly writing a whole app in CFSCRIPT rather defeats the point in using CFML, and one should probably be using ASP or Java if they want to code like that, but then the same could be said to writing OO code using CFML as well, both are rather defeating the original attaction and goal of CFML as a language, but the advantage is that it gives people options and they can choose what road to take.

I would imagine most people who learn CFML for the first time just start off using basic tags and writing procedural code, but then as they learn and progress they will end up writing OO code and using frameworks if that floats their boat. For those in the OO camp having CFSCRIPT more robust and functional is probably a plus, as it suits the OO paradigm better, which in effect will further separate the procedural and OO camps. Yes that could result in people writing god awful unreadable code, but this is nothing new for CFML as that has always been one of its downfalls, because it is so easy to pick up the basics, learn a few simple tags and write an application, the world is full of very poorly written, insecure CFML apps. At least with CFSCRIPT/OO you do need to better know what you are doing so writing crap code is less likley to happen by accident, but rather by design.

But those who think they are a better cfdeveloper just because they write everything in CFSCRIPT are most certainly spending too much time with their head stuck somewhere dark and damp.

> I suspect the framework authors will be > rubbing their hands in glee; yet another > way to obfuscate their already over > complicated design so others find it > difficult to use,

Erm...I'm a framework author, and I despise CFScript, but I also don't object to its becoming a "first class" citizen.

I just think it's silly to use it when it's basically Java-lite, or almost-Groovy.

+1 to Ben's mentioning of deprecating CFScript for server-side AS3...

Interesting set of comments. I do agree with Alan's point about "I am not against a scripting language, I am against inventing a new one."

CFScript is a bit of a bastard child. I'm totally on board with more of a scripting syntax in ColdFusion. I just wish it was another, more formalized language than cfscript. There was plenty to choose from. ActionScript would have been nice, and hopefully that will be implemented at some point in the future.

I do understand that CFScript has been in place for a number of years and it made sense to fully implement it (finally) but realistically, it doesn't really help new developers come in to the fold, because they have to learn the custom CFScript syntax, and can't really use a more established syntax.

It would have been nice to leverage existing parsers, tools and other stuff that would be in place from using an existing language. That said, I'm just happy for some alternative from tags as they have less density than a pure script syntax.

DW

The problem was the cfscript was never really completed, it was a half-ass'ed attempt at a scripting language to begin with.

Back in February when I first heard that cfscript was going to become a real language I was excited, now I am no longer so sure. I now think that cfscript should have been tossed out and action script used. I mean why the hell not? Actionscript is a full blown language by now, why flesh out something that was never fully thought out when there is a perfectly good language waiting in the wings?

Just need to provide a cfmx libary and we are good to go!

@Terrence: thanks for your input, and its great to see CFIMAP as part of the core language. Only took around 5 years to get there after BlueDragon introduced it. ;)

I take your points about CFSCRIPT -- but wouldn't it be better if it was truly JavaScript or Java compliant? At the moment its mimicking Javascript, with a hint of Java. I am not against a scripting language, I am against inventing a new one.

@Charlie: understood. thx

@Alan - I fully support your right to dislike cfscript both personally and professionally (I'm sure knowing this comes as a great relief to you) :)

I do agree that cfscript seems to be in sort of a "limbo" (no pedigree, as it were). But it's moving in the right direction.

As I said, I did used to like cfscript (and it wasn't for a perceived "performance boost"... as I understand it, any performance boost that may have been there ceased to exist with CFMX 6.1). I was comfortable with the syntax, except for the operators. Moving back and forth from JS to cfscript was a bear, as I'd write cfscript with + concatenators or JS with & concatenators or... you get the idea.

I think the improvements in CF8 ("real" operators) are a HUGE step in the right direction. Full tag support is another step in the right direction, as that's what got me to move away from cfscript in the first place.

I don't know that I'd move back personally. I've gotten used to the tag based syntax for functions and love being able to specify cfarguments as being required or not (as well as default values). So at the end of the day, I don't feel that I really have a horse in this particular race.

I think it might be a tad dramatic to suggest that giving folks the option is the equivalent of killing CFML though. Those that want to use cfscript will. Those that don't will continue to use tags. I can see where it could potentially create a rift, but I hope that won't be the case. I don't think it will be, at least.

I suppose only time will tell. Up until then, we can only continue to be... well, assumptive :)

Two notes:

The advisory committee is totally having an impact. If nothing else is clear proof of that fact, let me point out that the Advisory committee establishing cfimap as core CFML was a major reason behind implementing it. But more than that, Adam has publicly committed to working with them, he has been doing so.

But I would also like to address the point of cfscript being the wish and desire of the "cool" or "clever." I too was one of the masses who used cfscript, then abandoned it because it was not full featured. I would have to say I was against implementing full cfscript. But it got in the alpha and I started fooling around with it. I found I liked it. Flash forward, I get hired by Adobe, I start doing more coding in it. I'm debugging a particularly repetitive CFC in CFML - I notice I'm having trouble finding my spot. So I play a hunch figuring all of those people say cfscript is more readable, let me test that out. So I refactor the cfc into cfscript. You know what, for me, it was a lot more readable.

So I'm in a place where I use CFScript for my backend code, and CFML for UI and layout. Analogous to (but not the same as) the divide in Flex between MXML and ActionScript. If I have to do queries, I tend to do them in CFML, if I have to work with objects, I tend to do cfscript.

The special sauce of ColdFusion is in my opinion, the ability to use it the way you want to use it. We are enabling yet another way. I honestly don't believe it detracts from the language and products as a whole.

Terry

@Charlie ... as I understand it, the Advisory Committee is not yet of a level yet where they are truly influencing. This is probably more of a case, the tail following the dog, because we are not yet at the point where the committee is really deciding the direction of Adobe. CF9 was in the works way before the committee was established and in full throws.

So to give the committee the full credit for this - i believe is somewhat wishful thinking. From my view point, this is an Adobe initiative.

I am for a happy and healthier CFML community. I am permitted my own personal views, which is why you are reading them here, and not on the OpenBD mailing list or blog. I do not speak for OpenBD, and I am sure the rest of our growing community have their own, probably, contradictory views.

For me personally, CFML is a tag based language. I was never a fan of cfscript from the start and have always disliked its inclusion. I was hoping it would die off as Java became the standard for the underlying platform. But Allaire/MM/Adobe missed a trick there I believe. CFSCRIPT should be pure Java if we are to have any sort of scripting language. Or even better, JavaScript 1.3+. But at the moment, its neither, with no real pedigree to hang its hat on.

So I am sad that CFSCRIPT has been allowed to distort instead of tightening up what could have been a great addition.

@Alan - Thanks, I do my best to entertain :)

Assumptions aside (and of course, there are assumptions as I'm not privy to all of the inside info as to what exactly went down between Adobe and NA, but I like to think I'm intelligent enough to piece things together), fine... let's ignore the past.

Today, you're attacking Adobe when they're not the entity behind the decision. If you're truly speaking as Alan Williamson the individual, then attack the Advisory committee.

But alas, the Advisory committee acts on behalf of the community.

As far as making assumptive posts... pot, kettle. Do those that use cfscript do so only to be thought of as "cool" or "clever"? Do people do it to stroke their egos (thinking that doing so places them in the "top-etchelon of CFML uber-gods")? Or could it be because they are comfortable with the syntax and think it's less verbose than the tag-based equivalent?

In fact, the entire basis of your post is assumptive, is it not? Adobe is killing CFML. But if Adobe is acting on behalf of the Advisory committe, which in turn is acting on behalf of the community... then the community as a whole is getting what they want. In turn, this should translate to a happier community which means a healthier CFML.

You can point the finger at me all you want for being "political". Bottom line is you could have made your point without attacking your competitor, so you made it political long before I did.

All of this is IMO, of course :)

No offense Alan, but I remember the exact same rants when cfscript was first introduced. Frankly the arguments used are just as stale now as back then.

From what I've seen Adobe was responding to developer input. A significant number of people were asking for this feature. What does it mean to developers/coders who prefer to use CFML tags? Probably not a lot. You'll continue to use CFML tags and ignore or use cfscript as you've done before. if you need the feature its there, and if you don't you don't have to. No problems. Everyone wins

I look forward to full cfscript support and know of many developers that are aswell. Full script support will also help new comers to ColdFusion especially people straight from College who are used to programing java, php etc and not used to tags all over there code. Working with Flex and ColdFusion and jumping between tags and script is annoying especially as I do almost no mark up with ColdFusion and my logic code is full of tags where script would be a neater solution.

As for the alternate engine supporting cfscript Railo already has this planned so it should just work on there engine and I assume OpenBD will do the same.

I'm also not sure how it can kill CFML if tags are still fully supported. If you don't like it don't use it.

@Charlie: another assumptive post! This has nothing to do with any rifts of any kind. I speak as "Alan Williamson" not as "Open BD" and I have never been a "New Atlanta" employee. But good of you to try and make something political out of this. Very entertaining.

thanks for your input.

Wow :)

I have to assume this sort of attack on Adobe was a big part of the rift between New Atlanta and Adobe... which resulted in OpenBD not being part of the Open CFML Advisory committee initially.

So OpenBD folks complained (which I don't disagree with... in spite of the past I think that all of the CFML engines should be represented), and are now part of that board.

This same board is meant to "speak for the masses", no? The board represents the community and speaks/acts in the communities best interests. To Adam's point, the cfscript support was vetted by that community, which includes an OpenBD representative.

So why attack Adobe as the entity that "speaks for the masses", when OpenBD actively campaigned to be part of the entity that actually does?

As far as the issue at hand, I'm with Brian Rinaldi. Initially, I did like cfscript because it was often more concise than tags. But because of the lack of implementation of all tags, I found myself breaking in and out of cfscript blocks too frequently to make it worthwhile, and got used to tags.

I'm neither vehemently for or against the full cfscript implementation. Although you ask, "You can already use Java within CFML pages, so I am not sure why you need this.". I don't really understand what one has to do with the other, but not every CFML developer knows Java. Full cfscript implementation gives CFML developers (not Java developers) a choice. cfcomponent and cffunction aren't going to magically stop working just because there's another option available.

In the end I don't think it's about being "cool" or "clever". It's about using what's more comfortable to you as a developer. Nice to have that choice.

If you disagree, take it up with the Advisory committee... not Adobe.

@Adam: thanks for your reply. You can't put 2+2 = 22. Just because I personally dislike the whole language dropping down to just one tag, doesn't translate that OpenBD will not be supporting it. Should we hear our users demanding it we will of course follow. As of yet, we aren't hearing it. Maybe that will change. Matt keeps us all in the loop, so don't worry on that front.

@Ben: What a wonderful suggestion, and that is something I could really get behind (regarding AS3 at the server side). I just don't like the smell of where cfscript has gone -- its over stepping its mark, and becoming something it shouldn't. If people want a full blown scripting language, then lets come up with something way better. If AS3 is the way to go, then so be it.

Hey Alan, actually, I am in the same camp as you. I am not a CFSCSRIPT fan and do not use it myself. And personally, I would love to see CFSCRIPT deprecated in favor of a full server-side AS3 option (something like what we sneaked at MAX last year). But, at the end of the day the team tries to provide what users ask for, and lots of users have been asking for this one repeatedly for years. In fact, when I talked about this at usergroup presentations recently, this received all sorts of applause (second to spreadsheet support, of course!). This is not Adobe speaking for the masses, it's the masses begging the ColdFusion team for this, and doing so since we first introduced CFSCRIPT back in ColdFusion 4! So, despite my misgivings, and with considerable input from the CFML advisory committee, CFSCRIPT becomes a first class ColdFusion citizen.

--- Ben

Why is it that you feel Adobe is killing CFML just by providing an option to the tag based syntax? Its still the same language. And believe me, Adobe wouldnt be adding it, if it wasnt something that a significant amount of ColdFusion developers werent already asking for. There are alot of us that want it. You dont like the script style syntax, dont use it. Its a choice, just like using a framework.

Thats your choice to use one or not. THATS the real beauty of CFML is the freedom it provides different levels and styles of developers. You wanna write procedural code in a tag based syntax, fine. You wanna write procedural code in a script syntax, fine. You wanna write OO or MVC style code, fine.

But to say Adobe is killing the very product that they are IMPROVING based on the community's suggestions and requests is just plain silly and for lack of a better term, ignorant.

Are you serious?

You completely glossed over the key to that quote: "if you are so inclined."

The great thing about ColdFusion is that you have <em>options</em> to do it one way or the other; whichever suits you. You are just posting flame bait and a more than a bit short-sighted.

All the language enhancement for ColdFusion 9 were vetted and recommended by the Open CFML Advisory committee (including full CFScript support). You should talk to your OpenBD representative (Matt) instead of blaming Adobe. I've made it very clear that Adobe should _not_ be driving the future of CFML. That is a role best fit for the community.

Based on your disdain for CFSCRIPT, does that mean that OpenBD isn't going to follow the CFML 2009 recommendations?

-Adam Lehman ColdFusion Product Manager - Adobe

Seems to me you are making a big deal out of nothing. If you don't like cfscript, don't use it. What is with this CFML religiosity that seems to have come out of hiding this year. Why does the community need to subscribe to any individual's sense of what is "pure" CFML?

Nonetheless, I, for one, used to use cfscript a lot but have since stopped. Not because I didn't like it but because it didn't support many tags I needed so I kept having to close the block and reopen. It wasn't in any attempt to obfuscate anything that I used it...it just felt comfortable, especially jumping from ActionScript (which was Flash at the time no Flex) and CFML. I also found it often easier to read because it had less noise. Its a personal preference...one which I think many people (especially those coming from other languages) share.

In the end I don't think people pick languages based solely on whether it uses tags or script If they do that's nuts which is why your suggestion that you change languages if you want script is silly. However, for some people coming into CF from other languages, the scripting may feel more comfortable and, in my opinion, that's a good thing.

@Chris thanks for your reply. Sadly you can't qualify sweeping statements like "large part of the community". We all know the vast majority of CFML developers are silent. Ben Forta has always talked about the majority of people only using a handful of tags. So i really don't see how it is any more than a small vocal minority claiming on the behalf of people who don't care.

But that aside, you are right you can ignore it. But i am talking as both a CFML developer, and also as a lead of a CFML engine.

As Ben states, it is no longer CFML; so what is it they are creating? Where are the pulling our beautiful language to? You can already use Java within CFML pages, so I am not sure why you need this.

OK, so you dont like cfscript. Dont use it.

If CF's mantra is 'this is so easy to use!', then why not make it as easy to use for Java programmers who are used to that syntax, as it has been for HTML developers with the tag syntax? I really dont see the issue you have with this, cfscript is not hurting anyone, and a large part of the community has wanted it for quite a while.

This article is wonderful, thanks Alan for coming out and sharing this.

I would like to predict that Adobe will do to CFML what Microsoft did to ASP--keep bastardizing the purity of the language (you see it already: adding CFSCRIPT, OO, frameworks, etc) and convoluting things until you have two camps: the ".NET ASP" people and the "Classic ASP" people. And we all know what people like to use!!

I get the sense that you, Alan, as well as most of the other CF luminaries will fall into the "Classic Coldfusion" category.

Viva la CFML!!!