Overall review of cf.Objective() and thoughts on OpenBD and the CF9 BOF
First of all, if you're a mid to senior level ColdFusion developer, you REALLY SHOULD attend this conference next year. There's no substitute having access to 280 of the top CF developers in the world in one hotel. I can't tell you all of the great conversations I've had over the those four days (including Day 0). You'll learn all sorts of new ideas you might not have considered.
I've said it before, as have others, but the sessions and speakers were top notch. Most of the ones I attended were sessions I had already seen at user group meetings or CFMeetups, or even read in FAQU, so I didn't really get that much out of a lot of them, but still picked up one or two things I might not have known. I may try to get out of my comfort zone next year, take a different strategy and try to attend sessions on things I am not as familiar with to round out my knowledge.
The conference has a developer "feel" to it. In other words, it's not as polished as a MAX or even a CFUNITED. That's great in some ways because it really makes it feel like it's developer grown, not a corporate money-making thing, and it's intimate enough that it was easy to meet up with CF developers and get into extended conversations, both ColdFusion and non-ColdFusion related. That said, there were a few things I would have liked to see a bit more "polish". At the reception on the evening of Day 0, the guide and the website (which was down for a while on Thursday) said 9pm, but it started at 8pm, so I got down there at 9:10 and they put away the food by 9:20. I felt like a horse's ass not realizing that the bar wasn't a cash bar thing. If there were signs, I didn't see them. During the conference, the A, B, C and D rooms kept shuffling. That was a bit confusing, but the rooms were fairly close to each other, so that was OK. If it had been a bigger conference area, this would have been a bigger issue.
The food was not bad. I've had better, but it wasn't bad. There was usually some food or beverage available. The only time there wasn't was during the BOFs. That was one thing I appreciated at MAX last year (although Adobe really botched publicizing the BOFs).
The hotel was nice, probably one of the best I've stayed at for a conference. I had a nice room and the Sleep Number beds were the best I've ever had in a hotel.
St. Paul was... kind of dull... of what I saw of it. I didn't get a chance to go into Minneapolis or the Mall of America (I missed Iron Man), so I might have had a better impression if I had. It was quiet, which is not a bad thing, especially during a conference.
So... next year... come to cf.Objective()! I heard there are some thoughts about expanding it to other continents. I don't know if that will happen, but this conference is a good one to make it to. If I am grading the conference, I would give it an A. It would have been an A+ if it had a tiny bit more polish, but that's still a high mark.
The rest of the blog post will focus on Open BlueDragon and the CF9 BOF, which I had both mentioned in my day 2 post.
Open BlueDragon
I still find it quite ironic that, just as Jason Delmore was going to announce an open source initiative for ColdFusion, one of the audience members had a seizure. The next day, relatively quietly, the Open BlueDragon beta was released. It will be interesting to know what the significance of both of those events will be in a year. I think Open BD has the potential to do wonderful things for the CF developer community. We'll just have to see. Competition is good. I think an open source, stable and fully featured CFML engine will finally give Adobe some good competition in this space.
If you look at the Open BD source, you'll be impressed by how clean it is. If enough ColdFusion developers look at it, I think you'll see many CF developers take to Java. It's really not that foreign when you look at the source. One thing that intrigues me with looking at the source is the possibilities it could bring. If you are finding there's a tag or function you want that doesn't exist, add it to the source! If you find some limitations to... say... CFHTTP, for example, make modifications to the source code to make it more robust! Whether you contribute that code to the project is up to you and the steering committee. The reason why I mention it is you are no longer stuck to the existing tags and functions for your CFML projects. You can add your own in a way that CFCs, UDFs and Custom Tags never could. It's food for thought.
CF9 BOF
I am still quite surprised and shocked over how the CF9 BOF focussed on AS3 support instead of hammering Adobe on the need for a ColdFusion IDE. I noticed my Day 2 post said twice that perhaps the audience took it for granted that Adobe IS working on an IDE for ColdFusion - I guess that shows how much it perturbed me. I've read several blog posts about the "divide" in the room, and I'll address that later, but I think many of them don't realize that I don't think it's what they thought it was.
Having access to ActionScript3 in ColdFusion would be a good thing, don't get me wrong, as would the ability to make CF XML compliant, but NOT at the expense of breaking compatibility. If you are building a new application, I think more robust CFSCRIPT, AS3 and XML compliance would be a GREAT thing, but NOT if it means it's a pain in the ass to port my applications to CF9. If you are advocating that, forget it. And if you are talking about Adobe choosing a path that makes it very difficult for companies to migrate existing applications to ColdFusion 9, you need to be very careful what you are suggesting. If you are a consultant, this is great for you. You don't have to live with the applications you create, and maybe those companies will hire you again to re-architect those apps, but this is fantasy talk. GET REAL. Adobe would NEVER develop a backwards incompatible CF9. For one thing, it would cut down their upgrade sales drastically, not to mention how it would affect ISVs who sell ColdFusion apps, and open source applications and frameworks.
Back to the "divide". Several bloggers have mentioned this "divide" between developers during the CF9 BOF, almost a class distinction between those developers that want a radical change in the language over those that were just asking for new features. Since I was one of the developers asking for new features, I guess that puts me on the "wrong side of the tracks". Instead of it being the "big thinkers" vs. the "lesser minded developers", I think it was a divide between those that have a love/hate relationship with the language and those that love the language and have learned to embrace, or at least work with, its limitations.
I think those that were asking for a radical change really need to decide why they are using ColdFusion in the first place. If they REALLY need this change, perhaps what they need to do is change languages. Move to Groovy, Ruby or Java. I am NOT saying there's not a valid reason for AS3 in CF. I am saying that's not where I'd start making changes in the engine.
I wish I didn't have to tell people in my presentation to be very careful when creating large arrays of objects because ColdFusion is a performance pig in that situation and that they should consider doing an array of structures. I wish that a fully OO solution would give good performance... but in CF8, it doesn't.
I am a pragmatist. I try to create well performing, stable and easily maintainable applications, but I do that using the language that I am working with, developing well structured code, and that thing between my ears. I don't try to develop ColdFusion in a way that doesn't make sense from a performance standpoint.
OK - so object creation is a pig. Rather than throw out the language, shouldn't you tell Adobe, "Please fix object creation?" Why is it necessary to overhaul the language to fix performance?
On the same discussion, I agree that CFC creation can be a pain in the ass and that we need something better. Wouldn't it be better if you could use CFSCRIPT for everything? Do we REALLY need AS3 to overhaul CFC creation? Sure, it would be nice if you had a fully object oriented scripting language in ColdFusion. However, why is it so important that we need it?
Is it envy? Do you wish you could tell your "cooler" Ruby, Python or Java developer friends that your language is fully OO, too? I wonder.
I think the need for AS3 in ColdFusion is displaced. If you want to overhaul the engine, I think your best bet is to get Adobe to create an AS3 J2EE server. Don't kill compatibility. Think of all the companies that never upgraded after CF5 because of incompatibilities between 5 and MX. Some converted to another language and never upgraded.
Also, I have to comment on the tone I am seeing. I don't appreciate those that act like they are better than others because they don't share your "vision". I live in the real world, and my world tells me you do not turn ColdFusion into something that breaks RAD and compatibility. Learn to use ColdFusion wisely, and stop trying to turn it into something it is not.
Could ColdFusion have better ties into Flex? Yes, but that's not exactly what you spent most of your time asking for. I wholeheartedly support better ties into Flex, and I think we'll see that in CF9.
Adobe should make CFSCRIPT be full-featured and ECMA compliant (but also allow it not to be), fix object creation so it's not a dog, spend some time marketing CF to the Enterprise for more than just intranet development. Done right, ColdFusion is an EXCELLENT public facing web platform, but Adobe always seems to push the intranet features like PDF, reporting and .NET integration. I wish Adobe would focus on getting more hosting providers to support CF and get CF in the classroom so it's not so damn hard to find good CF developers.
And, Adobe build a good ColdFusion IDE for goodness sake! I really don't love any of my choices for a CF IDE today, and I'd be willing to PAY for a good one.
At the very least, if not build an IDE, I'd like to see Adobe help out with CFEclipse. Mark Drew needs help building out CFEclipse, and you'd think Adobe would have a vested interest in supporting a good IDE. It seems like Dreamweaver and ColdFusion are distancing themselves from each other. Dreamweaver is certainly wanting in many respects as a CF IDE, but I still prefer it on a strictly code editing basis (in other words, the code view). If CFEclipse had </ to close tags, and not be wonky on a few things, I would probably switch to it... but CFE is still not there for me. I will say, though, that I am starting to use it more than I have before.
I'd also like to see Adobe open source Homesite+. If they aren't going to offer it anymore, open source the damn thing so that others may support it. I realize that Homesite+ only works on Windows, but I could see someone taking the bulk of it and porting it to Eclipse, writing a Cocoa version of it, or porting it to Wine/Darwine so it could run on other systems. I've not seen that blogged anywhere, nor was it mentioned during the BOF, so I thought I'd mention it here.
So, there it is... I finally got out one of my LONG blog posts. I imagine this will get a few comments. If you don't agree with me, that's great. My opinion is just that and you are entitled not to agree, but I thought it was time someone talked from the "other side of the room".
http://www.brianmeloche.com/blog/trackback.cfm?B63C63D9-3048-2E57-0ACAB35B333F760C
I like how you mention you are a pragmatist. I tell this story a lot - but one of the creators of CF has sai he built the language to be practical, and I think that really speaks to the power of CF. It may not be a beautiful OO language - but it is a language that is easy to use.
Perhaps those guys really should think about changing languages if they're that unhappy instead of trying to strand all of us who disagree on CF-8 as he suggested. I am a CF and ajax developer and I think we represent a pretty sizable group in the CF community. I have no desire to have AS3 forcibly integrated into the language I love.
I appreciate daily what Mark Drew has accomplished but my number one feature request for CF is for an IDE. For most of us it's all about rapid application development and an Adobe CF IDE would advance that cause.
@Ray: Thanks. When I say I am a pragmatist, I say that with pride.
@Tony: Brian K is one of the people that is advocating this radical change, and, quite honestly, I understand his points. It's where he talks about breaking compatibility that I really have a problem with. If you break compatibility, that makes the upgrade that much more difficult, and most of us support existing applications and build on them, Joe Reinhart has been much more level headed in this discussion, and I think his attempt to build a Groovy loader is the right way to attack the problem. Use a language that is better than ColdFusion to build pieces of the model rather than break the CFML engine. Andy Powell is also advocating using Java for the model. My main problem with Andy's take on things is that you don't NEED to do this for your entire model, and using Java exclusively for your model takes the RAD out of your model. From what I know about Groovy, this is a good middle ground, pragmatic approach that Joe is talking about, and I look forward to what he comes up with. It reminds me of Sean's approach for using PHP and Ruby language in ColdFusion, although this implementation seems quite different.
@Rick: It's my pleasure. Good luck at the summit. I wish I was joining you.
I'm sure many will see this as me knocking ColdFusion, but I'm not. I use ColdFusion heavily (obviously) and it's a great product. For the current project I'm on at work, the PDF functionality alone is worth the cost of ColdFusion 8. I just want to make sure people understand the distinction and start thinking about the opportunities an open source alternative gives them. I think finally having a real choice as CFML developers is a fantastic thing.
I wholeheartedly agree with you, Matt. Open BD is not going to be the solution for many use cases. If you depend upon the PDF functionality, for one, or the AJAX functionality not yet in Open BD, then Open BD will not work for you. However, it is an alternative that will be attractive in many cases, and I look forward to what comes out of the project.
An interesting side point on the whole AS3 argument, tying the two BOFs together, is that I would strongly doubt that Open BD would ever support AS3. I also think that if Adobe doesn't fix object creation performance or CFSCRIPT improvements (I don't upper case my tags, by the way; that's just for effect here), the Open BD team might do so. I haven't really worked with BlueDragon much so I don't know if the object creation performance issue exists to the extent that it does in ColdFusion. Turning off type checking in CF8 does improve performance, though - I will say that.
Interesting times are ahead. CFUNITED should be interesting this year, as I expect we'll hear more about CF9 and hopefully Open BD will be at or near a 1.0 release.
I would *love* better object creation performance. Not because I want to hang out with all of the cool kids and say my app is OO, but because being able to create more objects allows me to do a better job of creating more maintainable apps and while I hack the process in CF with "Iterating Business Objects" and a bunch of Singleton facades, it would be nice not to have to do so. Honestly though, I think it was the underlying decision to compile every method down into its own class that would make this much more radical surgery than would make business sense for Adobe.
Easier integration with Spring and Hibernate a la Groovy might be something to consider, although I don't know if even the ColdFusion team can make hibernate and spring truly easy - I'd love to see their efforts though - that could be a very interesting direction.
I understand what you're saying about suggesting people choose the language that best meets their needs, but I'm not convinced it's in Adobes best interest for anyone needing to create rich performant models to use Groovy or JRuby. When they start to do that, all you're left with in CF is some cool tags for the view layer and special tags for images, pdfs and the like. I don't think Adobe ColdFusion is worth the money if you're just going to use it as a view templating language, and if you need pdf or images, you could stick CF on one box, do RESTful calls to that to use all the magic CF tags and build the rest of your app in Groovy. Works for the developer, may not be so great from Adobe from a revenue perspective as I'd imagine it'd put a hole in the number of licenses per installation.
I know there was a small but vocal minority at the meeting, but I think it is worth considering what they were talking about as where they have gone, more cf developers will end up over time, and I think now that there are credible choices for dynamic scripting on the JVM other than ColdFusion, Adobe's going to have to carefully blend positives (new tags that'll get people to upgrade) with fixing negatives (lack of a complete script based syntax for the model and the cost of component instantiation) to continue to make CF more than worth the cost of the license.
Whatever happens, I think the debate in the community is great as it can only give Adobe more data points from which to make their business decisions.
I want to see more feature complete CFSCRIPT syntax and better object creation performance so that many of the points I made in my talk, as well as Nic Tunney, are moot. Until we see this, these discussions are going to keep coming up and those outside our community will continue to say we're not ready for prime time.
Instead of joining the talk of the other side of the room, I choose to build CF applications the best way I can, and not be hung up in OO theory. Theory doesn't make CF applications perform.
Those who don't agree with me (I've gotten some emails on this discussion)... Believe me, I understand what you're telling me. You are frustrated with the limitations of the CFML language and performance and see alternatives like Groovy and JRuby which don't have these limitations. I GET IT. I just don't agree with your reasoning. I do not agree that correcting those limitations is worth the changes you are proposing and the effect it will have on backwards compatibility and RAD. You can get most of what you want without breaking compatibility and making it harder to develop your CF apps, with CFSCRIPT improvements and better object creation performance. That's where we need to focus our feedback, not on AS3.
That being said, I totally agree that introducing a new language into the mix is the way to go. We have "another" language we can use with CF--it's called Java, and it performs quite well, thank you. I think the people pushing for AS3 inclusion in CF are way off base personally. It doesn't make sense and I really hope it doesn't happen. The most frequent justifications I heard from people when I asked why they wanted it all began with, "Well if you're doing Flex ..." Fine, then push for Adobe to make a Flex server, but cramming AS3 into CF isn't the answer.
Maybe people aren't talking about the open initiative on the CF side because there isn't all that much to talk about, at least not yet. A public bug tracker gets a big "So?" from me at this point. How much buzz did you really think that would create? We'll have to see where that goes, and as I said before, any move in this direction is very welcome as far as I'm concerned, but I just don't see anything worth jumping up and down over. Not yet anyway.
As for AJAX functionality, sorry, but the AJAX stuff other than cfajaxproxy (which is very cool) in CF 8 is pretty unusable. It gets a big wow factor because it's so easy but if you get into using it in the real world it has rather severe limitations and very bad performance (in my experience at any rate), and based on this you find yourself moving to a real AJAX framework pretty quickly anyway, in which case this "advantage" of CF 8 really isn't one at all. They'll get much better I'm sure since this was a 1.0 release of the AJAX functionality, but right now it's more frustrating than helpful IMO.
Quite frankly, the amount of extra work to do something with jQuery is pretty miniscule, with the payoff being a lot more flexibility and far, far better performance. I just reworked an app that had been using the HTML-based cfgrid to use jQuery instead and it didn't take any time at all, and the performance is far better.
I said a bit about AS3 in my other comment, but frankly adding AS3 to CF is about the dumbest idea I've ever heard, no offense to those pushing for it. Most of the people I've heard pushing for this can only see it from the Flex perspective and aren't really looking at it beyond that. I'll leave my comments on that topic there for now (although maybe this will spawn some better discussion and justification for why this isn't the dumbest idea for CF ever ;-).
As for the OpenBD being at 1.0, just to point something out, OpenBD is the J2EE version of BlueDragon, so the open source edition IS that edition at this point. It will be moving to an official release cycle of its own and will likely start to diverge from the J2EE edition in terms of features, but I don't think people should shy away from it because it's not "1.0." It has several years of development behind it and is the same as version 7 of the J2EE edition, and there is some very cool stuff in the works for the future of that project.
I completely agree this is a VERY interesting time to be a CFML developer. We have more options now than we have in the past, and I think the CF community is getting mature enough that we're starting to look at the world beyond CF and demand more from our CFML engines, as well as investigate alternatives for those occasions where (warning: blasphemous statement ahead) CF just isn't the best tool for the job.
On the AJAX stuff, I happen to agree with you. The CF8 stuff is pretty much unusable with the exception of CFAJAXPROXY. I only mention it if some companies are using it anyway. That said, I wouldn't, and I am not. I am under NDA, but I think I can safely say we chose another way to do our AJAX other than the built-in stuff - and it's working quite well.
Did you make the BOF that night? I didn't see you until afterwards, so I assume you weren't in there. I agree that they are looking at things from a Flex perspective. That fuels the desire, but it's misguided. That's not the way to solve our issues.
On Groovy, I've looked at it, although I haven't tried to write anything in it yet (too much work going on to experiment much). It does look quite compelling and I think that Joe is on the right track with the way he's going about it. I only wish that he didn't NEED to do it - that CF didn't have those limitations. There are other ways around it - like using an array of structures in CF vs. a pure OO design. True, it's not a pure OO solution, but I would choose that to go to my systems architect or IT director as the solution over a Java or Groovy solution simply because that would generate less warning signs for them, and it makes sense to solve the problem within CF than outside of it. Of course, if you call the shots or need the OO, develop it in another language. There's nothing wrong with either solution. As I have said, I am more Scotty (engineer) than Spock (scientist), so I choose the less theoretical, more applied solution.
Great post.
I agree.... cfscript + object creation performance.....
No, but Java does. And there's absolutely no reason you can't have RAD in Java. It may not be the dominant idiom, but there's nothing crazy about it. I currently have two instances of Eclipse, one with a Java workspace and one with CFEclipse. The build button in the Java instance compiles and deploys my jar file onto my dev server (takes about 1 second) where Javaloader picks it up. The point is that building and deploying the java side is about as hard as hitting the save button on the CF side.
As for Spring/Hibernate - there's some housekeeping integration code that's a pain, but you do it once. Then it's the same for every project. So hire a Java contractor to get over that initial hurdle, then have fun.
OK, this approach is not for everyone. But there's no way this stuff is too hard for people who are putting together sophisticated OO apps anyway.
I don't disagree with doing it in Java if you can, but why do you have to? Isn't the main performance pig the creation of beans? Can't you keep the SQL and service functions in ColdFusion and do the bean in Java? The way you're using ColdFusion is as a tag library, and an expensive one at that.
I agree that, if and when you need it, doing your heavy lifting in Java is not just a good, but a GREAT solution. I guess where we differ is in the extent of using Java for everything in the model vs. using it only where it's needed.
I also choose the applied solution (array of ColdFusion structures) vs. the theoretical (array of Java objects) because I don't see why everything needs to be an object, especially when you are just returning a list (just to be clear, I am talking about returning a list here on reads on LARGE arrays). It's not a question of skill, Andy. It's a question of philosophy. Where you need it... like it you are doing a bulk insert, for example, yeah - Java's the way to go. I just don't buy that you need to throw out modeling in ColdFusion altogether. You, and others, are free to try to convince me otherwise.
I am not against scripting improvements in ColdFusion 9 - quite the opposite. I WANT THEM! It's the NEED for AS3 scripting in CF that I am questioning here, and making scripting improvements that would break compatibility. I would think adding an attribute to the cfscript tag that would send the engine down a separate interpreter path would make the most sense, rather than breaking the old cfscript.
It really comes down to a shift in the way CFML developers approach ColdFusion. Approach it as just another J2EE app in the J2EE stack and you open up doors that have previously been left unopened to both Java and CFML developers.
As far as "developer skill", do you mean to say that every developer has the same skill set and understanding of those skills? Come on. What I mean is this: the more skilled you are with a language, the faster you can develop an application with that language. Couple that with a strong IDE (which is generally a function of the language) and you get truly rapid app development / deployment.
On the last paragraph, I was not saying that at all. Not every developer has the same skill set, nor do they all have the ability to achieve the same skill set. That's a given, and I didn't feel that it was worth commenting about in my previous reply.
First, the idea being suggested by some that because I think CFC creation is too slow and that tag-based model development is too verbose somehow means that I should just drop ColdFusion is pretty poor. I love ColdFusion. I love the fact that it makes so much hard stuff easy. I want to keep using it for exactly this reason. Why should I have to switch to Groovy or Java simply because I'm daring to suggest that there are problems with ColdFusion that need to be addressed? In the end, those may actually be the answer (build your model in something else), but before we hit that drastic point, I'd like to exhaust the other options first.
I surely hope that making radical suggestions to Adobe does not somehow make me condescending, or mean that I should just be told to switch languages. I said over and over in my post and comments that I am NOT trying to be condescending. I understand exactly why people disagree with my suggestions. I knew the idea would be controversial when I posted about it. I definitely didn't mean to be offensive or arrogant. I don't think that a suggestion to Adobe is offensive, or that pointing out a set of problems that are being mainly felt by people doing more advanced development with Flex is condescending.
@Tony, thank you for your kind words but your earlier post about being offended by my post is a bit worrisome. Most people who have met me would tell you that I am a pretty open-minded guy. I spend a huge amount of time trying to help other people by posting examples, answering questions, and contributing to discussion forums. I hope that the fact that we disagree on this set of topics can be kept civil and rational. I personally love debate and frank discussion!
@Brian: It was good to meet you at the conference. I do realize that there is a continuum of ideas that I was throwing out there, and that the idea of switching to XML syntax and fixing longstanding language issues would be one of the more unlikely and difficult items that Adobe would consider exactly because it would break backward compatibility. I was simply saying that for me, personally, I would accept that break if it meant fixing those issues. In my mind, sometimes it's necessary to do something like that. I know they won't actually do it, or at least I'd be stunned if they did. I was just expressing my own opinion that I don't think it would necessarily be a horrible idea and would in fact have a number of advantages to consider as counterpoints to the drawbacks.
I also agree that an IDE is badly needed. I give mad props to Mark Drew for his work on CFEclipse, but the effort one one guy and a few occasional contributors just can't equate to the effort that Adobe can and should be putting into a CF IDE. I was quite shocked that when the idea of an IDE came up at the BOF, everyone basically shrugged their shoulders. I've heard from the Adobe folks that their IDE survey pretty much told them that most people thing CFEclipse is fine and that they woudn't pay for an IDE. Which I think is pretty crazy, but everyone has their opinion. I told Adobe that I'd pay $800 in a second for a CF IDE that was as full-featured as FlexBuilder. And I meant it.
As Matt alluded, and I had also mentioned a few times in my post on the subject, I would also embrace a FlexServer that addressed these needs and targeted people specifically building back ends for Flex apps. My only fear is that if Adobe creates two servers, and the FlexServer handles all of these things, that eventually CF is going to lose that battle.
The problem with saying "just use Java for your model" is the effort it takes to actually integrate the two. If you've ever tried to leverage Spring or Hibernate from within a CF model, or had to litter your CF code with JavaCasts, then you know the sting that it leaves. Since AS3 is much more dynamic than Java, it would seem to provide a nice intermediary. Done right, it would also mean a reduction in duplication on the Flex and server side if the two could actually share code.
In any event, I actually agree with much of what Brian is saying here. I would happily take a revamped scripting language or some degree of more seamless Java integration, as well as some alternate method to create objects aside from CFCs, or much faster and more efficient CFC creation. If they do that with CFScript, great. If they make it stupid easy for me to use Java, great. If they add AS3 support (and the benefits that offers for integration with Flex as well as the floodgate of people that would love to leverage their existing AS and JS skills on the server), great.
We are, after all, just trying to have an open-minded and frank discussion on how we can push CF to even greater heights. I personally see this as wonderful, and am thrilled to see the community so engaged and passionate about the range of ideas being thrown around.
All our love of CF (and even its recent sales success) doesn't have Adobe out there touting CFML as the future of web development (but they are touting Flex and thereby AS3). So, while I support the whole initiative in the first place, I think fighting it as vehemently as some folks do is counterproductive since I think in the end keeping it out of ColdFusion (the app server not the language) will be harmful to its viability in the long run.
As for the "divide". Much of what has made the ColdFusion product continue to grow and maintain relevance came from these very folks (maybe not the exact same people but the "advanced" or "thought-leaders" in CF). For example, they were touting the need for object-oriented development abilities when I was writing queries in my views and personally saw no specific need for things like components. So I wouldn't go ripping on people like Brian K or the group at the BOF for trying to press the limits. I would expect nothing less and appreciate that they do it.
In fact, let me say that if it weren't for them we would get more features built to impress the non-technical managers who often control purchasing. We have plenty of this crap in ColdFusion right now. We all know those features. They have that "cool" factor in a presentation but in the end you never use them (and since we won't touch backwards compatibility we are stuck living with them forever). This has left me wondering if this is a negative side-effect of being the "expensive" solution next to a bunch of "free" solutions (and we all know they aren't always really free but we are dealing in perceptions here).
Anyway, that is a discussion for another time as my comment has gone on long enough...
I've attempted to stay quiet in this debate and watch where it goes but I have to speak up at this point. I have a hard time calling folks that want to destroy the core language in favor of their new toy thought leaders for a platform. I am not saying that those folks are not ultra intelligent or very advanced, or even thought leaders for Adobe's product line in general. I just no longer see them as ColdFusion Platform thought leaders though after the remarks in the BOF, in this respect I still very much appreciate everything they do for the CFML community. If this is ColdFusion's thought leaders then ColdFusion needs new ones.
CFML is a good language riddled with lots of issues due to way too long supporting backwards compatibility. Something needs to be implemented like a "Strict" setting (like HTML) to allow the gradual transition into a nicer/more performant language (for example always scoping your variables). Adobe sets out to create a Platform (not a language) and that was what they were looking for in this discussion. Mostly what they got in return was how CFML sucks and AS3 was cool and good. Don't get me wrong I think the language needs to evolve but scrapping CFCs (essentially) and replacing them with AS's implementation is NOT evolution.
For anyone that wants AS3 server side could you explain what the advantages of this would be over something like jruby or groovy? I just don't see the cost benefit there. Sure if it was free, great, but I do not see that happening. Why in the world would Adobe do this and realistically cannibalize their ColdFusion market while still not selling to the, larger, Java community, it just doesn't make sense to me.
Where I think we don't, or perhaps didn't, have common ground on is with respect to compatibility. Keeping people on CF8 is not a good solution, but I sense you are backing off from that position a bit.
@Brian R: No, I wasn't trying to rip on those people, but I was trying to sincerely ask if the request wasn't coming out of envy, especially if it's out of a "me, too" kind of thought process. That said, all of this discussion here, on Twitter, and in other blog posts, has given me some food for thought for another, more conciliatory post on the subject. Essentially, most of us are trying to solve the same problems, but have come up with different solutions. That's a good thing.
@Adam and others: If you could allow compatibility, but also allow a stricter language that addresses many of the performance issues (I gather that CF's looseness affects performance, from posts I have seen and what I've seen of the Open BD code), as well as scripting and object creation improvements, would that make CF9 more compelling for us all? Just a thought. I don't even know if that's plausible or not, but it would certainly make sense from a non-CF engine builder perspective. I'll blog more about this tonight, too.
[ /snip ]
Stay Classy, dude!
However, taking the details of the medical situation aside, knowing that the person is alright, and focusing on the effect of what happened, I still find it ironic that Jason didn't get to fully make the announcement he planned. No one but Jason and the Adobe guys knows if there was anything more beyond that slide, and it's natural to speculate and wonder. It was a big announcement, potentially anyway, that wasn't. Instead, the big things coming out of the conference was Open BD and all of the fallout from the CF9 BOF, which we're still talking about days later.
Regarding why AS3 has advantages over JRuby or Groovy: Adobe already has a ton of tools and services built up around AS3. They already have a large developer base using it (multiplied many times over if one includes JavaScript developers since that is also an ECMA-compliant language). Server-side AS3 would open up a vast new world to these people, and allow them to leverage their existing skills instead of forcing them to learn yet another language. That said, I'd be more than willing to entertain the idea of allowing seamless integration with something like Groovy. I just think that given Adobe's already huge investment in AS3 and Flex that it is worth serious consideration as a server-side language as well.
I can accept the reasoning for AS3 serverside on a personal level for a developer. You have some valid points. If I were a company evaluating it I don't personally think anything you stated would be a compelling reason for me to invest resources in providing the functionality.
On a personal note I think there is a very small gifted segment that is good with client side and server side and honestly in general I think there is (and should be) a dichotomy between the 2 arts. Oh and I failed to mention Jaxxer in the list earlier (the best of them in many respects). If you want ECMAscript on the server check out Jaxxer.