1. "Optional" Primitive Data Types (int, long, String, boolen etc)
2. "Optional" Strongly typed language (int a != int A)
3. Improve the Collection Framework Availability.
I think the above "Optional" features when turned on would help translate CFMX CFML
closer to Java Contructs.
Joe Eugene
----- Original Message -----
From: Dick Applebaum
To: CF-Talk
Sent: Monday, June 28, 2004 9:16 PM
Subject: Re: How does CF generated Java bytecode compare with Native Java bytecode
OK, I think I agree that a machine transformation (sift) of one
programming language (architecture) into another will likely be
inefficient. I've seen enough of these (sift programs) in my computer
experience that I understand their limitations. But I also understand
their advantages -- often the quickest, least manpower intensive way to
get from A to B.
Often what you save in manpower, you can spend a small fraction on
additional hardware and have a wash.
I know it isn't elegant, but it is practical -- and sometimes the only
way.
I guess, the question is is it (CFMX Java) good (efficient) enough?
There may be a lot of other contributing factors:
-- The longer learning time or ramp-up for native Java applications.
-- the availability/unavailability of competent Java programmers
-- the life of an application
-- the maintainability of the code by others.
-- selfishly, my ability in CF vs Java
These are very subjective considerations --
All things considered, can I create a reasonable Java program (mainly)
in CF.
Stated another way, could CF be a "RADD Java development language" for
the rest of us?
Isn't that the main reason that IBM is remarketing CFMX?
Dick
On Jun 28, 2004, at 5:12 PM, Barney Boisvert wrote:
> It'll definitely be much worse than if you write it in Java, no
> question
> there. There's simply no way to make a machine transform one
> language into
> a second language with the same proficiency as a human writing the
> second
> language directly. CF is an amazingly high-level language, and
> droping it
> down to something as "primitive" as Java is an enormous task.
>
> However, before we go too far down the road, is this topic anything we
> should care tremendously about? Obviously we don't want to use slow
> software, but Macromedia knows this, and they understand that if their
> product offering isn't up to par performance-wise, no one will buy it
> (JSP,
> .NET, PHP, etc. are waiting for us). We as CF developers have an
> interest,
> but we can't do anything about MM's CF engine either way, so why even
> care?
>
> <heresy>If you want a fast application server, don't use CF, pick
> something
> else.</heresy> You'll have to deal with DB connections directly,
> roll your
> own mailing scripts, and whatever else, but that's the tradeoff for
> performance. Personally, I'm very happy making that trade.
>
> Of course, I'd be quite interested in a discussion about how the CF
> engine
> works, but not in a performance sense, but rather a "lets find out
> how it
> works" sense.
>
> Cheers,
> barneyb
>
> > -----Original Message-----
> > From: Dick Applebaum [mailto:[EMAIL PROTECTED]
> > Sent: Monday, June 28, 2004 4:56 PM
> > To: CF-Talk
> > Subject: ROT: How does CF generated Java bytecode compare
> > with Native Java bytecode
> >
> > There were some threads a while back that indicated the Java source
> > generated by CFMX 6.0 were inefficient (big and/or slow) compared to
> > the same app written in native Java.
> >
> > I wonder how CFMX 6.1 measures up.
> >
> > To narrow the comparison (a little) lets assume that there are valid
> > CFMX best practices, and that the CF programmer is above average,
> and
> > follows the best practices where warranted.
> >
> > Anyone have any thoughts or experiences?
> >
> > TIA
> >
> > Dick
> >
> >
> >
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
