> The biggest deterrent, I have found is the long learning curve. Sure, but I don't think the learning curve isn't as much the syntax as it is the conceptual differences between procedural and object-oriented programming. Time and time again I have seen the difference in thought processes be the "brick wall" that most people run in to, including myself for the longest time; not necessarily the syntax.
> After this rather long preamble, here's my point: > > If CF had inline Java code, it would allow someone learning Java to > take a segment of a working CF program and recode that in Java -- > without the need to "learn everything about Java", including its > theory, structure, syntax documentation, etc., "all at once" > > You would have the familiar CF infrastructure supporting your "Java > segment". > > You would have the advantage of starting with familiar, working code -- > and tasked with developing the working Java equivalent. > > You likely would comment out the CF code, and replace it with the Java > -- you'd have a side-by-side comparison to ponder. > > You would likely begin with infrequently-used segments of programs > where "less than optimum Java programming" would not be a severe > penalty. > > As you applied this technique, you would have more and more questions > about Java and you would find the answers (of necessity) and your > search would reveal more of the Java approach. Dick, I don't necessarily disagree with what you're suggesting, in concept. However, I just think that it's one thing to have Perl and CF side-by-side (procedural vs. procedural) for learning purposes, but it's an entirely different thing to have Java and CF side-by-side (OO vs. procedural) in the manner you propose. It's two completely different thought processes. While I understand this isn't a feature that everybody would use, I would personally like to see MM focus on encapsulating some more Java features into easy-to-use black-box CF tags rather than having to code my own Java. I would also like to see them focus on cleaning up the underlying code/engine that makes CFMX work to make any performance improvements they can; not complicate the engine by allowing for new in-line Java. I don't have any specific gripes about the performance, per se, however I'm sure there are areas that their engineers would like to go back and tweak. After all, this was a version 1.0 release, in a matter of speaking. > Finally, you should ask yourself why a company like IBM wants to > teach/market ColdFusion along with its enterprise Java offerings -- I > would speculate that the simple answer is: "because it makes sense -- > Java with CF offers better productivity to a broader audience, than > Java without CF." -- and that translates to $. I think IBM wants to do this because the time-to-market using CF is drastically smaller than Java. Again, as I did in a another thread, I point to a ComputerWorld article I read where the major Java vendors are exploring ways to implement a CFMX-type approach of encapsulating the Java syntax in easy-to-use tags. The corporate adoption of Java hasn't been as high as these vendors had foreseen, and with the advent of .NET, they need to keep ahead of that camp. I think that MM should keep their current focus on using this approach rather than offering the in-line Java feature. Regards, Dave. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
