Ed,

You know I am a person who is open minded and flexible enough in accepting realities and truth. If the reality is "I can't have both two worlds", fine with me. Those are just wishes and dreams or say it "Nightmare". But don't slamn me on your end notes. Now, you may have no bad intention on saying it but it's not good to read at least in our culture. Consider it also that I am natively an Asian - not English speaking per se - and it's therefore your duty as Americans to communicate with us in an acceptable and easily understandable manner. You need to bend yourself in order to reach out us out.

About you saying that this is not Christian community but VFP community, forget about it because on the first place UT has it's policy right?

>>I think you need to review all those posts again. Jess isn't quite as innocent in all this as you would like to make him out to be.
>>
>
>It doesn't matter; it's as if the problem didn't exist.
>
>I don't think it would've been any better had I suggested that he re-examine reality for himself rather than he stop bullshitting himself (damn, there's that word again...), it's the suggestion that I felt his argument was an unrealistic view of the world (ie "I want all the new toys, but you'd better not change anything or I'll go pout in the corner.") I think he misses the fact that the domains of the two interpreters, the VFP Runtime and the CLR, are fundamentally different in behavior, and that he can't have it both ways (eg IL strong typing and structures vs the loose, flexible internal behavior we have now with VFP variables.) The result of .Netification of VFP p-code to be IL rather than p-code (which requires a runtime, which requires installation, yada, yada, yada) would force us to lose the behaviors that give VFP its unique place in the development world.
>
>We've already seen one platform, Java, where the concessions of compiling to a common p-code run cross platform, even though it worked (well, sort of worked most of the time) did not give the performance that emitting platform-specific object code did; if the argument in favor of VFP is blinding speed, kiss it goodbye going to the CLR platform.
>
>There seems to be a belief that since both CLR and VFP's runtimes are run-time interpreters, and since we postulate that all languages languages contain the same linguistic constructs, they should be interchangable. That misses the key issue; even though certain basic structural similarities exist, the two interpreters do not talk about equivalent domains. There are things in each that are not directly translatable in a simple fashion, because the things being described do not exist conceptually in the other's world-view. We see this frequently in spoken languages; there are words and phrases that don't translate between two natural languages. We get around that by taking contextual clues and imagining a different domain from the one described by our native tongue. But there are things where you just have to say "I can't describe it."
>
>Unfortunately, in a formal language, "I can't describe it" translates roughly into "GPF". There are programs which can be written in VB but not in VFP even though they both run on a Win32 platform, and the opposite is also true.