Adobe Should Stop Trying To Make CF Like Java
Simon Horwith recently posted a list of features he'd like to see in ColdFusion 8. The timing of this is interesting, because just this weekend I was speaking with Hal Helms and Mike Britton about the future of ColdFusion. Simon's post prompted me to write about our own discussion on this topic.
The trend lately seems to be to try and make ColdFusion into "Java Light". BlueDragon is adding static methods and interfaces. Adobe has floated the idea of adding interfaces as well. Simon is asking for things like method overloading and constructors. Whether we're doing it consciously or not, we are effectively asking Adobe to shoehorn CF into a Java mold.
The question I would ask in response to this is "who is this trend toward a more Java-like language going to benefit?" Obviously it will benefit a core but dedicated group of developers who understand what interfaces and static methods will offer. I'll be the first to say if CF added interfaces or static methods I would probably use them. Though at that point, the old "why don't you just write it in Java" argument gets harder and harder to refute. But more importantly, is it going to benefit the majority of CF developers who have only recently (if at all) started to grapple with issues like OO? I would say the answer is no.
OK, so if one accepts that these advanced features will truly benefit only a small (but growing) core group of developers, is there anyone else that these features might appeal to? Is it possible that they might entice non-CF developers who already use Java, C#, PHP, or Ruby into using CF instead? Could Adobe leverage the new features to grow the CF community?
Again I would have to say no. Why would someone that uses a language that already supports OO far more deeply than CF does decide to switch? I just don't think this is going to happen except in very isolated cases.
What Hal, Mike and I came to wonder is: what if Adobe stopped trying so hard to make CF into Java Light and instead focused on the thing that CF truly excels at? If instead of trying to beat Java in a game that it can never win, it went down a road that would truly differentiate it in the web development space?
I'm talking about the presentation layer. CF might pale to Java or C# on the OO side of things, but it beats every other platform when it comes to creating application interfaces and easily bringing data to the user. Imagine if instead of spending their valuable and limited development time on OO capabilities that appeal to a fairly limited audience, Adobe brought the hammer down on every other platform by making CF's presentation capabilities absolutely devastating.
We've already got graphing and Flash forms, cfoutput and basic validation. I'm saying they should take that and turn the dial to 11. Integrate Flex with CF so seamlessly that you can essentially create Flex apps from within your actual CF pages. Like Flash forms but infinitely more powerful. Or if Flash isn't your cup of tea, allow users to easily bind data into AJAX-powered components that go way beyond Spry. Go take a look at Backbase and then think about what it would mean to CF if they made it simple to create those components and feed data to them.
And while they're at it, let me create complex DHTML layouts and UI elements with just a few CFML tags. Keep going with the PDF and LiveCycle integration, to the point where one way a user can provide data is from PDF forms that the user completed offline and later synchronized.
The more one starts to think about it, the faster the ideas start to flow in. But I think you get the general idea. If Adobe did this, then they would have something to really draw in people from other languages as well as make existing CF developers' and customers' jaws hit the floor. Instead of fighting a battle that they just aren't going to win (the OO battle), fight where they already have the lead and have the potential to become overwhelmingly dominant. Let's make developers from every other language look at the insane presentation capabilities of CF 8 and bow their heads in shame.
I'm not saying Adobe should not give us any new features in the OO arena. I'll use them as quickly as any of you will. But I fear that this is becoming a sort of obsession within the "upper echelon" of the community, and that we might be so focused on it that we are missing a really great opportunity. I know Adobe is planning on better Flex integration and maybe even AJAX capabilities. I just think instead of being "nice extra features", these capabilities should be the most prominent and critical additions, garnering the lions share of development resources. What do you think? Are Hal, Mike and I off our rockers? Or are we on to something?
My reason for not wanting Adobe to try and built JavaLight is that CF is great for people with not much programming background, while also keeping people with that background or interest busy. When I started with CF around 1997/8 it was the only option for me. There were a lot of alternatives which were either to complicated or not complicated enough, CF fit the bill.
For someone with javascript/html knowledge CF is perfect, if CF gets too abstract it will loose that advantage.
CF already has the best database integration with ease out there. Now if thy could integrate CF more with image capabilities, like croping, resizing images with a Flash or DHTML interface that would be killer. Also tighter integration with Photoshop would be cool.
Of course, let us not forget the whole Ajax and Felx stuff....
It's like with the recurring requests for proper image manipulation and handling features in Coldfusion... Ever since MX the standard response seems to have been "you can just use the underlying Java features". Well, if I "could just" as simply write everything in java, I wouldn't need to sit on 3 Coldfusion server licenses.
Flex is great - but is another layer of complexity - it is getting nearly impossible for the CF 2.0 original user to configure and load the 5 peices of software to get things to work. All the guts have to be taken back to the 2.0 ease of use level - then users will go "CF ROCKS".
Does this require better examples, docs, training for market use:
Describe sales force performance - customers - salesmen - products - margins - selling expense, open orders and backorders. How best to use grids, charts, bindings, drill downs, export to PDF, EXCEL, etc
Let's go back to the future - go to ease of use for presentations.
Go CF.
I think this kind of mentality will eventually kill CF. NO ONE IS ASKING FOR CF TO BE JAVA. I think at that point we'd just use Java. In Simon's list, he gives a perfectly good reason why interfaces would be a good addition to the language, and it doesn't have anything to do with making CF "java-lite". Why does PHP5 have the OO features we are looking for? Probably because PHP developers were sick of debugging terrible code written by their peers who refuse to acknowledge that you actually have to put *effort* into programming. Sure, CF should excel at front-end work, but to say that enhancing the backend or language features is something we don't need is very short-sighted IMO.
We are not asking for the same features of Java and C# - compare CF to its dynamic counterparts -> Ruby, PHP, Perl, Python! You'll find that CF is EXTREMELY lacking on its support for OO constructs!
Just because we want interfaces doesn't mean we want Java interfaces. As a framework author, interfaces are a great way to document how the public API of my framework is supposed to be used. This is *not* a fringe case - for most large applications I also set up a public API for developers to use - it should be in an interface not some stupid abstract class. Don't think we are the only ones going through this growing pain: http://dirtsimple.org/2004/12/python-interfaces-ar...
Your post basically says "I can't convince anyone to use CF for large projects anymore so why should it have features *useful* to large projects?" Thanks for sealing our fate.
As far adding a new language constructs to aid framework development, is fine but it shouldn't be on cost of new functional features. CF is lacking lot of daily use capabilities related to CFCart, CFReports, Imaging etc.
Simplicity of language constructs with lot of daily use utilities is a winning combination. We can take the example of Java language development, now days their manager emphasis is on make language/plateform easier to use.
--- Ben
This is the reality.
Think of Coldfusion as Spring Framework but a bit more expensive.
Many coldfusion tags ( cfquery and others ) could be easily replaced with JSTL tags, then what the point of using Colfusion ?
The worst think for Coldfusion is trying to make it an Application Server.
COLDFUSION MX 7 is not an application server.
For me Coldfusion is just a framework for RAD and it's damn good at it....
Why are we trying to make an another oop layer on top of java ?
Shouldn't we use java as our core oop language and use Coldfusion as a glue which is the role it had in the past ? ( Remember Coldfusion with java object or com object )
What are Coldfusion's real values :
- simplicity
- display layer ( flashform,flex,pdf)
Who's is using event gateway ?
Here are ideas for a better Coldfusion ( maybe stupid ) :
- free Coldfusion engine ( no search tools , no pdf or flashform) simply the cfml engine ( see railo : faster than Adobe CFML).
If you want to spend hours with open source projects (
lucene,IBatis,Hibernate) do it.
- not free out of the box pluggable options :
- verity search option
- flex option
- flashform option
- Event gateway
What do you think ?
By the way what the fuzz with cfthread tag ?
This tag is just DANGEROUS !!!!!!!!!!!!!!!!!!!!!!!!!!!
A lot of coldfusioners are struggling to understand interface and other oop
concepts and you are trying to add threads in Coldfusion ????
If you are application is too slow, first check what going on with your objects ( CFCs ), but please don't think that threads are going to solve your problems.
Or if you really need it, do it with java object and plug it with Coldfusion.
Serge Tan Panza
See: http://devnulled.com/content/2006/07/wishlist-11-t...
And while I greatly respect you, you seem to be missing the fact that *you are the fringe case*. Of course interfaces will be useful to you. They'd be useful to me, too. But the average CF developer isn't writing frameworks! To the vast majority of CF developers, the addition of killer presentation capabilities would have a far, far greater impact than the addition of something like interfaces.
I disagree that my post is "giving up". My point is that if you really and truly need to create a huge domain model, doing it in CF is probably a mistake. Why not use Java, which is specifically targeted at something like this? Why could CF not provide more seamless integration with Java domain models for these extreme scenarios, and then make it a no-brainer to leverage that data in CF-powered UltraFrontEnd? If people (like me!) still want to write their models using CFCs instead of Java classes, that is still a fine option. This seems to have the most positive impact across the board.
Why not add some better capabilities as part of CF for testing the code? This way no one has to create interfaces for checking the type of object. Your test will varify it.
Not to parrott what everyone else has been saying.
But these are the exact same things I have mentioned to my colleagues off the record, with regards to CF and its future.
I agree 100% with extending ColdFusion's presentation capabilities. Since Flex has been out I had been predicting more and more of a CF/Flex integration, to the point where you would be able to write a CF App with all the UI of Flex by using additional tags. But with all this push to make CF Java-like, I wonder if that's going to happen.
But the number 1 thing that I and my colleagues in teh Field who have used CF for almost 10 years, are hoping for is more Live Cycle integration. Most of the people I work with and have worked with, do a lot with PDF's, so more of LiveCycle integration would benefit a large percentage of CF's customers. I think that a large percentage of CF shops are government organizations or organizations that are affiliated with the gov't. Having worked for such an organization, they do a lot with PDF's and I'm sure would benefit from more of a LiveCycle integration.
Anyway, great post.
cheers,
Ali
Do we really need to get so entangled in Java and OOP stuff? Take note of this famous warning against - it probably originated from the makers of a competing programming language: "OOPs; I did it again, I played with your heart, got lost in the game". Let's not get lost in this game, eh? :-)
I agree wholeheartedly with this post. Focus on the presentation layer, make it easier and faster for me to build my interfaces! The Flex integration was a welcome and completely refreshing step. I look forward to what Adobe can bring to the table in the next few releases in regards to enhancing the presentation layer develoment cycle!
Apart from improving the presentation layer, additional attention to data connectivity would also speak volumes. By far most business projects are the quick-and-dirty apps that do single function things..supporting fast development of a pretty app that connects to back-end data would help immensely.
I've always thought that the 'evolution' of Lotus Notes was hurt more than helped by the focus on Java support applied by IBM's direction. Notes apps that we used to be able to churn out using @formulas took longer in script and still longer with Java. The whole RAD thing that Notes was famous for was lost.
Sometimes companies catch a bad case of feature-itis and forget about the whole KISS thing.
But - like it or not - this stopped after CF5, and CFMX's implementation of CF Components. These are blatantly a move away from the "it's all about the front end" side of CF. And now we're "stuck" with them.
So CF started to be positioned on two fronts: RAD front-end stuff; RAD BACK-END stuff. There's nothing wrong with this, and indeed it sticks with the central axiom of being RAD.
I guess the distinction here is catering to two groups:
1) website developers;
2) web-application developers.
(I fall into the second demographic)
I'm all for adding things that personally perceive as bells and whistles (cfdocument, cfchart, maybe something new like cfimage), because I website developers can get a lot of benefit out of them? Me: no.
However CF can make a fairly good case (but this could do with strengthening) for being used to develop applications as well as websites, and do that quite quickly and easily. And to create applications, the developers might need a different featureset. I don't see what's wrong with that. If you don't need things live event gateways and CFCs... don't use 'em. But don't suggest they're not exceptionally useful (crikey: CFCs were the best thing EVER to be added to CF, in my view).
And enough with this "Javafying CF". That's just nonsense (sorry Brian: it is). Anyone declaring that suggesting adding constructors and interfaces (and a few other odds and sods) to CF is making it like Java is just silly. They might be helping make CF more OO, and what's wrong with that? WHY should CF stay as a procedural language? There's nothing wrong with procedural code, but there's also nothing wrong with OO-style code. And indeed one does not need spectacles and a propellor on one's head to get one's brain around OO concepts, and it makes for much less work and more maintainable and reusable code when one makes the effort (this has got to be an appealing prospect!). One can get by just fine with procedural code, and indeed any CF app is going to be a mix of both (my UI stuff is procedural, my back-end stuff is as OO as CF will allow it to be. Kinda), but having OO-esque capabilities also deeply improves the RAD-ness of CF's application development.
And don't forget... any new application-development-centric bells and whistles which don't appeal to someone using more CF5-centric CF... can simply be ignored. No-one's FORCING anyone to use anything. So if you want your code to follow KISS: ignore the more complex stuff.
As a quick rebuttal to those who suggested "if you want Java... go use Java". Well I'm a CF developer, and - I think - not a bad one. But my Java skills hover around the "Hello World" sort of level. If I had a few months, I'm sure I could learn Java. But I don't have a few months, I need to get my work done NOW. And things like CFCONSTRUCTOR and CFINTERFACE would make my job a lot easier, in places. More easier than adding new features to CFDOCUMENT or CFREPORT.
Anyway. That's my 2p.
--
Adam
Bingo! Bingo! Cha-Ching! Arrrough! Arrough! Yes Baby Yes.
I'm sure a freebie Eclipse plug-in for Flex 2.0 will present itself fairly quickly.
I think you're right, though: the impetus beind adding UI features to CF might have diminished not that it integrates so tightly with Flex. Which sux. Because when I *do* do UI stuff... I want it in HTML, not Flash. I'm still to see to much Flex/Flash stuff that is actually *useful*, and sufficiently better than an HTML solution as to take the plunge into Flex.
--
Adam
I think that ColdFusion should differentiate on the power of flex and ajax integration and should look at UI components and other tools to make it easier to develop powerful, cool apps. But the cool apps need to consume and persist data and there HAS to be a powerful back end supporting that.
For me, it is not a choice between CF and Java. I do a lot of dynamic programming and metaprogramming in CF that I simply couldn't do in a strongly typed language. If I was to leave CF it would be for Ruby (not Rails - I like DHH and Joe was a little harsh recently, but I'm not a big Rails fan) as the metaprogramming capabilities are cool and the syntax has a lower S:N ratio that CF tags.
However, I've been programming in CF for 9 years and have no plans on giving up. I just don't want to see CF degenerate into the presentation tier for Java developers. There need to be enough OO capabilities to make CF a credible end to end solution for most mid sized projects.
Best Wishes,
Peter
Incidentally, how did that 'bot bypass the Captcha text? Unless spamming is now being out-sourced to India so they can do it by hand? ;-)
Are you talking about my enthusiasm? I'm simply a hearless emotional bot now? I would cry, but like the tin man I have no heart to generate the correct feelings. Maybe a Regular Expression may help me find my soul. :-)
The point is, when Adobe divides up their resources to work in features for the next release of CF, tradeoffs must be made. One option is to spend a lot of time on adding OO features. But the benefit of adding these is confined to a very, very small segment of the CF development community. Another option is to spend a lot of time adding killer presentation capabilities. The benefit of adding these applies to virtually every single CF developer on the planet. This is not difficult math in my opinion.
Let's be honest here: the vast majority of CF applications being built are data-centric. They involve taking data into and out of a database, displaying it to the user, and letting them modify it. What percentage of CF apps would you say fall into this category? 95%? Why not play to this strength?
Someone here mentioned that they are happily looking forward to using interfaces and static methods in the CFCs. Then in the same breath came the admission that they don't know Java and don't want to learn it. I don't want to ruin some big secret, but Java isn't that hard. I'm by no means a Java expert. But by far the hardest thing about Java is learning object orientation. If you already understand why you'd want to use interfaces or static methods or any of the rest in your CFCs, you're most of the way to understanding Java.
I would ask why we need to re-implement all the more advanced OO features in CF. Let's say you are in the small minority that truly needs to build a giant, complex domain model (not just CRUD but real business logic). Why can't you use CF for what it is good at (presentation and common tasks like queries, email, LDAP, etc.), and use Java for the more complex stuff? What if, instead of trying to add these features directly to CF, Adobe made it totally transparent for one to leverage Java under the hood?
The existing integration with Java is good but it could be better. Hal mentioned one great addition would be the ability to use JavaCast() to cast an object to *any* type, not just a small set of primitive types. This is just one example. It seems to me that Adobe could easily hit a sweet spot here, with killer presentation capabilities, a fairly robust existing set of OO capabilities in CFCs for smaller to medium-sized apps, and seamless integration with Java for the extremely complex stuff.
Finally, when one says the idea that CF is being "Javafied" is "nonsense", this baffles me. Does this mean you think that CF is NOT becoming more like Java? How can you look at the push going on and seriously try to deny that CF is morphing into Java?
Thanks for all the responses, I think this is an extremely interesting topic and one that really needs to be kicked around.
But after a short time, I began to realize that Macromedia had been right to concentrate on the presentation layer of CF. Would I like some of the OO features that others have suggested? Why, sure, I would. In a perfect world, I'd have all that AND be rich (instead of so darned handsome).
But we live in the real world where costs and benefits must be weighed, as Ben suggested. Every dollar that goes into an OO feature is a dollar that does NOT go into building an absolutely amazing presentation language. My biggest OO-style wish would be for better integrationwith Java, but I'd be willing to forego all new OO features in order to see Adobe concentrate on crazy-great user interfaces.
Let's say that CF provided everything that PHP, Python, Java, C#, etc have. What do you have? Another capable server-side language that can be used (with some finagling) for presentation. With one difference: it costs money--and not an insignificant amount. That's a pretty tough sell.
But imagine CF with built-in Ajax, the ability to easily create Flex front-ends that are tied into CF's other tags (such as cfquery), a collection of widgets that also integrate nicely with CF (we already have some, I know). What language could possibly compete with that? Is it worth a thousand dollars? Oh, yes.
For a long time, Macromedia presented CF as "the fastest way to build Java applications." But, I don't think that's what the CF community wants. I think CF should be the fastest, easiest way to build absolutely killer applications, period. And, as I've said probably to the point of nausea, to the customer, the user interface IS the application. They expect, rightfully, for all that "back end stuff" to work.
In a world of limited resources, choices have to be made. And I think the choice to make CF the hands-down, no-brainer choice for application development would propel the language in a way that interfaces, constructors, static methods, or what-have-you won't.
"the average CF developer isn't writing frameworks! To the vast majority of CF developers, the addition of killer presentation capabilities would have a far, far greater impact than the addition of something like interfaces."
That's of course true but there's also great value in enabling these framework writers to continue/improve their work. In the end this will benefit the majority as well because they can use the frameworks to simplify and speed up their development process.
Most of the Java developers I've talked to want to switch to another language because using Java for web applications is too time consuming. A friend of mine compared it to using a sledge hammer to drive a nail. It'll get the job done, but it's a little over the top. I don't do much Java development, so this is just what I gather from talking to others (right or wrong).
From what I gather, the Java guys that are looking for something different are going with Python and RoR. I guess we should be questioning why RoR and not CF?
So, on one hand we have swithchers. On the other we have web developers. These are people that may be self educated in application development. I think these guys are the types you find in small web shops, ad agencies, departments in governmental agencies and in small/medium businesses. They use CF because it helps them get the job done quickly and simply. These are the people that use flash forms, reporting and document functions. These are the people that will benefit the most from adding image manipulation functions, advanced PDF presentation, Flex/AJAX interaction. They benefit because they may not have the time or resources to fully dive into each of these areas.
Finally, you have the advanced CF developers. They can do Java, ASP, PHP and anything else you can throw at them. They just prefer CF and want a more flexible back end. Forget the front end--the more OO features or Enterprise features the better. Strangely enough I fall between the last two. I'd like more of presentation and OO features.
So with this in mind, how does Adobe make CF into something that is unique? Can they make something that appeals to everyone mentioned above? Is that even possible?
The more I think about it, the more I believe that CF needs to be somewhere between RoR and Java: An application server that is offers RAD, is powerful and has great presentation features without becoming inflexible. Java seems a bit much for the job and I find RoR a little rigid. Both have some great features, but CF should offer the best of both worlds.
This is a great discussion and I've seen some terrific ideas. I'm starting to really dig the idea of more flexibility between CF and Java. In any case, I'll be happy to see more OO features or more presentation features (or both). I just hope that features added to CF 8 are robust and not watered down versions of more complex applications (Flex, Flash, PDF).
--Brad
Adobe should leave the CF to be the way it is now ..Dat's my 2 cents on it .
http://corfield.org/blog/index.cfm/do/blog.entry/e...
adimittedly it's to RonR, but the surprising thing is the amount of CF ppl now using Ruby.
some trends in the comments.
- most hate building simple apps in Java...too "heavy" (well...derr!)
- Ruby users are using it, not for the language, but because of Rails
- former CF people are using Ruby _because_of_rails_.
last count it was 140 comments, covering this and more. I'd be interested in ppl's thoughts re: this and CF8...
I am a relative novice compared to some of those commenting here, but I have to say ColdFusion and Flex ROCK! My biggest problem is that it isn't easy, for a novice, to get them to play together nicely. With the help of the folks at ASFusion, Ray Camden, Be Forta, and others, I have done some pretty amazing things (with my limited experience) with flashforms, but the inability to tie directly to charts and graphs, and use many of the Flex tools frustrates me to no end. The consumer and the board room don't give a damn about OO unless they can say Ahh! The only way to do that is through presentation.
I like Brian's overall position on what makes ColdFusion so unique and valuable and have posted some thoughts on my blog too.
I want enhanced presentation layer functionaity, and some of the OO functionality mentioned by others and some more enterprise integration and more beefy administrative tools. I am a greedy bastard ain't I?
To be honest, with every release of CF there are going to be things that some people use, there are going to be things people don't use. I can't even begin to list all the things I have not used in CF. There are going to be things that will definitely generate the 'wow' factor (and a lot of those will probably be presentatoin layer).
How many people 'oooo-ed, and aaaaahhh-ed' when they first saw Flash forms? I did. But guess what, the first application I planned to use Flash forms, I hit a wall that made them not a viable option.
By trying to use CF for presentation layer functionality, you are forced to use someone else's ideas of how it should be, or how CF says it could be. That's the kind of stuff I'd like to handle myslef.
Something I'd like to see would be like <cftemplate> where you could have some preset templates, or you could create your own, and then you content would be displayed within certain regions of the template.
Ok, this is now the longest post I have ever made on someone's blog, so I will go back into my hole now.
I could be way off base, here, but the content of much of what I read on these blogs suggests to me that most of our community's acknowledged experts (gurus, evangelists, architects, what have you) and contributors to these forums are professional software developers - much of what they pertains to writing software or the frameworks around which software is written. Please understand that this is not a slight of any kind for without professional software developers, APPLICATION SERVERS (Serge) such as ColdFusion would not exist and that would be tragic. However, I'm writing on behalf of "the average Joe". We aren't often vocal, but there are many of us, I suspect. We are the managers and systems analysts and coders in small, medium and sometimes large corporate IT shops. We wear many hats day in and day out...project designer, project manager, network administrator, DBA, web admin, help desk tech, application programmer, and toilet scrubber. I've done all these things (and still do), sometimes within the span of a single 10 hour day. There are 4 IT employees in my company (including me) and we are responsible for the daily (24x7) data systems operations of a growing and very busy company. Two of us are fairly decent ColdFusion programmers and know enough SQL to be dangerous. This is precisely why ColdFusion (and recently, Flex 2) appeals to us. It is an ideal environment (APPLICATION SERVER, Serge) to deliver attractive, reliable, data driven applications quickly and efficiently. I can assure you, my end users don't give a rat's ass about how their applications are coded. If the interfaces are not engaging and intuitive, or if, heaven forbid, the data is not accurate, there is literally nothing on that planet that will get them to use the application. In my world, a couple of projects that head in this direction and it's time to update your resume.
Talk in the ColdFusion community over the last year or so, perhaps a bit longer, about OO models and frameworks and business domain architecting, etc. has me a little concerned. I know these concepts have their place in the development languages that were designed to take advantage of their benefits, but I need ColdFusion to remain faithful to its roots. I truly do not have the time nor the inclination, not to mention the budget, to re-tool my department's programming efforts to accommodate far more complex development methodologies. And I know I'm not alone. Give me the ability, as Brian so astutely points out, to deliver jaw dropping user interfaces and present data accurately and in a manner that is beneficial to my end users without adding complexity to the ColdFusion development process and I'll be quite satisfied (which equates to a happy and loyal customer).
Many dyed-in-the-wool programmers might argue that learning and subsequently developing in OO and frameworks will benefit me in the long run….that my code will be easier to maintain and will be more re-usable. These things may be true, but they don’t represent a real high (or realistic) priority in the typical IT shop constrained by time, resources and budgets and faced with project lists that are pages long. To be honest, I’m lucky to get a few lines of code documentation in the average project. This is the world some of us live in. Improve ColdFusion….absolutely. But don’t turn it in to something that it was never intended to be.
I think you should package this blog posting and all the comments attached to it and send it to the ColdFusion development team. Most of the participants seem to agree with you and it would be good for Adobe to know what their customers really want.
Thank You,
M. McConnell
http://www.ryanguill.com/blog/index.cfm/2006/7/24/...
I'm 21 and I make money in my sleep BECAUSE I gave my heart to coldfusion 2 years ago. I tried php, even asp and got zero.
I also got two nice raises at my daily work (which I attend because coldfusion has made it easy to give what is asked).
My major at college is business - not even one computer class.
My site has more than 35000 members and works PERFECT all done with CF. And BELIEVE me my oo development skills lack 99%!
So let Citibank and Yahoo use all the oo they want, the majority of developers want simplicity and constant addition of great features that will make "our" lives easier and richer!
PS. How about a tag that extracts all pdfs from a 20 page pdf document into 20 separate pdfs and then another one that creates a jpg/gif image of the pdf!
PS. Sometimes us developers just start arguing and wanting more advance features only because subconsiously there is a battle between developers. Relax everyone, I'm making money because you are all blind into your development skills. I say let Ben and Adobe make our life ever more easy and happy!
There is a Greek saying... "whoever got it, got it."
Alexander
You are possibly all forgetting the importance of OO. CF is great at creating intranet applications and websites, but when you up scale to complex business applications where you have more logic than presentation OO is paramount.
I think Adobe should do both. Include support for constructors (simple) and give lots of nice prety features.
I just really hope all the nice prety features are NOT flash as it's slow. I think for every <cfform flash option there should be an equilivent DHTML / Ajax solution that works for people who don't want Flex / Flash.
Based on the user group I went to recently, i'd say there are a lot more hard core CF developers than you think.
Great blog entry. I agree with you 100%.
Here is my short wishlist:
I want to be able to create a Flex application written 100% in cfml. Flex 2 and the Mystic updater for CF is a step in the right direction so hopefully that bodes well for CF8.
My other big wish is continued enhancements on the reporting side. Improve report builder. Give me the same flexability in report builder for outputting data that I have with cfml.
I assure you Dale, I am not forgetting the importance of OO. Which is why I want more seamless integration with Java for the really advanced stuff. Why re-implement what is already there, just begging you to leverage it?
That reminds me of an ol Ben Forta saying, "Let the database do it's job!" It applies to this also, CF is good at certain stuff, Java is good at other stuff, the area where they overlap should not become to large.
I once had a great idea for creating a database model that was so abstract that it could hold any information you throw at it, until I realised that that database model was already there, it's called SQL Server.
I'm with you dude!
No!! You're wrong!! THIS thing is more important to the future of ColdFusion!!
You're 100% right! NOTHING is as important to CF as {thing x}!!!
*sigh*
It's all bullshit, really, all of it. There is no one thing that's more important to CF, the future of the platform, whether it's a server or a framework or a language (or all of the above)... the community is so diverse and the kinds of jobs that CF developers are being tasked with require vastly different tools, techniques and thought processes.
I wholeheartedly agree with the point Brian is making. Hal Helm's comment above about "every dollar that goes into an OO feature is a dollar that does NOT go into building an absolutely amazing presentation language" is dead-on. And it is not just about presentation layer improvements. I'm tired of begging and waiting (and more begging and more waiting) for additional features that would make CF a no-brainer choice as a development platform. Why don't we have features such as:
CFIMAP & CFZIP - BlueDdragon has it...why hasn't Macromedia/Adobe picked up on it?
CFEXCHANGE - Integration with MS Exchange server. My users want applications to access exchange calendars, create meetings, view shared contacts, etc. This is HUGE!!! It's a "killer-app" feature waiting to be implemented, Adobe.
CFIMAGE - Basic image manipulation. Insulate me from having to use Java or 3rd party components to create thumbnails, resize photos, etc.
CFFILE UPLOAD and CFFTP -- Let me upload a file into a variable instead of needing to write it to disk first. Let me put or get a file into/from a variable when FTPing.
CFSNMP or a SNMP Gateway Service -- Imagine the possibilities there!
Sandbox Security Improvements. As a hosting company, we're surely not going to open up new funtionality on our shared servers if there is any chance of compromising customer's security. For crying out loud, let me specify which set of CreateObject java calls/classes a site can use without having to allow/restrict the entire funtion. Also, there better be a way for us to restrict use of CFTHREAD if it appears...with that one tag called from one page, a malicious/incompenet customer could bring down an entire server!
CF's ability to create and incorporate tags that simplify and insulate the developer from hard/impossible tasks is what make the language a no-brainer choice. (Think about the beauty of the simple CFMAIL tag.) Having a myriad of OO improvements do NOTHING for us in this respect. IMHO, the "framework" and "OOP" cults have begun endangering the implementation of simple yet powerful functionality that will propel the language forward. I'm with Hal...I want that R&D dollar going someplace that is going to make the biggest bang for the most people/customers.
CFMX 7 *does* let you sandbox the different types of createObject() so you can leave component enabled but lock down java and com etc.
I still hate wishlists... and I still think that saying "eh write it in Java" dismisses a lot a good that people can do WHO DON'T KNOW JAVA (or not in-depth enough to do much good at it)... I'm with you in the last paragraph.
In fact, the core of my post on my blog and the core of yours paralell eachother in some respects. It IS the ease with which CF creates connections between FTP, email, database and web UI that makes it special... I just don't want to see features that will help continue to push us into the future set aside for enhanced cleaning products and brighter blinking lights.
RE: "CFMX 7 *does* let you sandbox the different types of createObject() so you can leave component enabled but lock down java and com etc."
True...you can enable components and web services via CreateObject, however enabling "CreateObject(Java)" is an all-or-nothing. We couldn't for example, allow a customer to harness the power of Java within CFMX (by enabling CreateObject(Java)), without also allowing access to java.io (which bypasses all directory Sandbox restrictions), sun.tools.javac Complier class, and other potentially devastating Java functionality that could compromise server security.
There is a lot of grumbling from shared hosting customers that such restrictions tie their hands from accessing the full potential of CFMX, and I agree.
I'd love for Adobe to extend the Sandbox security to allow specific CreateObject(COM) objects or specific CreateObject(Java) classes to be granted access in a particular Sandbox without opening the whole enchilada, so to speak.
CF is simple. It's "easy".
That's why way back when - when I was playing with learning HTML with Homesite and wanted to interact with a database - I looked at things like PERL, ASP and ColdFusion.
Let's see - 20+ lines of code to make a db connection vs. cfquery. Hmm. Hey these tags are just like HTML. After that there was no looking back.
If ColdFusion gets complicated to the point it's not "easy" anymore than you might as well use something else.
@Stephen: Sorry for mistaking your overwhelming enthusiasm for a 'bot. Good reply. :-) Or was your reply part of your AI? CFSMARTBOT perhaps? ;-)
you aint seen Tariq Ahmed's Unofficial CF8 Wishlist Survey?
http://www.surveymonkey.com/Users/49446542/Surveys...
----------
I assure you Dale, I am not forgetting the importance of OO. Which is why I want more seamless integration with Java for the really advanced stuff. Why re-implement what is already there, just begging you to leverage it?
----------
For me it looks like: "You should stop use ColdFusion because everyting is in Java". I'm using ColdFusion from more than 5 years and now I see I need move to other technology. Why? Because I'm working on project which has more than 2000 CFCs which is very important for company and not only for company. I'm working on this with my colleague and now we're expecting two new developers in that. We're scared because we can't be sure what they will do with (or using) our code. We can't stand on them all the time and tell them all the time how things needs to be done. We need to language which will not allow them cteate code like they want. I'm not buying the idea where every grapic designer can be a programmer.
For presentation layer I'm using Flex, not that "fantastic" feature like FlashForms. FlashForms - they were very good in Flex 1/1.5 time, when it wasn't free. Now for £500 I can have IDE which allows me to build much better UI than FlashForms.
If you're talking about duplicating functionality between Java and CF I need to ask:
"Why duplicate functionality between CF and Flex. Why you want improve FlashForms?"
As a developer building reasonably complex ecommerce applications, I could not have achieved half of what I have without the OO features. And the framework I'm now using (Model Glue) would probably not exist either. Being able to couple the simple syntax of CF with the ability to architect applications properly has enabled me to do some things that I simply could not have done without the OO functionality. And if Adobe wants CF to be the middleware behind Flex apps then it will need the OO features.
It would be greart to have all the GUI features mentioned above too. Tags that encapsulate AJAX and Flex would blast ColdFusion to the top of the pile in my opinion.
As somebody said above, I want it all! Especially as we've gotta pay for it.
I for one will never complain about features being added to CF which assist software-engineering types to architect better applications in the real world. Interfaces help me in team situations. I would assume many shops are like mine in that you have one or two highly skilled people and several junior level developers. Interfaces are something that can help me get better code out of my junior people. I don't see them as an OOP feature I think I'm missing but as a software engineering tool.
The second point I'd like to make is that small to mid-sized shops - CF's bread and butter - often don't have the budget to train people in several environments, nor do they often (see above) have an entire staff of people capable of picking up something like Java on their own. For a shop like this - like mine - it's important that I be able to do everything that can be reasonably expected of my shop in one environment. Sure I personally could code a given objective in Java, but if I'm out sick or I quit then my shop is stuck with code they can't maintain because they lack the expertise to do so.
I like the idea that we're getting constructors - I can't think of a good reason why we didn't get them out of the box in CFMX. I like Interfaces because they're a great engineering tool. But I do agree that we have to beware of the slippery slope and not get CF off track. CF's strengths are building web apps quickly from the middle tier out to the client and that's where a majority of development resources should go.
# Posted By Prabhat MOHANTY | 8/24/06 7:16 AM