>>
>>What would this gain you? If you write managed code in VFP, it means that you don't use all of the stuff that makes VFP different from VB. I guarantee you, managed VFP code will look so similar to managed VB code, that you could write a code converter with STRTRAN(). It's not worth the VFP team's efforts, IMO.
>>
>>Sure, CLR would give us new opportunities in VFP, but it would tie VFP to the ground in other areas. At the risk of sounding like a broken record: If you want something that looks, works, and acts like VB, why aren't you using VB?
>
>This makes sense but answer this and I'm seriously asking. Why doesn't this same logic apply to Fortran, Eiffel,Cobol, etc. Why don't they just tell their users to use VB instead of taking all the time and trouble to write for the CLR?

One reason:
I don't know about Fortran and Eiffel, but COBOL is syntactically very different from VFP. VB is already close. If you know VFP, you can already read most VB code. For COBOL programmers there is more of a reason to stay in COBOL because of the learning barrier. FWIW, I have no idea why anyone would want to write new code in COBOL. But that's not my area. :-)