>>Then why is there a C# and a VB.Net? Can't the same reasoning be applied to having a VFP.NET? Seems to me it can. Just as they are different from each other, having different adherents to each, so it is the case with VFP.
>
>Jim,
>
>My take on the languages supplied by MS for .NET is this;
>
>C++: Very low level close to machine
>C#: higher level but not "4th generation"
>VB: highest level "4th generation"
>
It's interesting to note that VB in the unmanaged code arena actually emits C which is then compiled and bound into an executable; I don't know based on my own experience, but I'd not be surprised to find that VB.Net is not a great deal more than a wrapper on C#'s CLR emitter.
>Now in my opinion VFP is also a highest level "4th generation" language. I think there is overlap with VB and VFB, but not with VB and C# or C++.
>
>Besides, they very things take cause me to choose to work primarily in VFP are what would be sacrificed for CLR compliance.
>
>Also if you think about it, having a CLR veriosn of VFP and also the full version is really two very different languages. Even if MS decide to make a CLR version of VFP the learning curve for moving from VFP 7.0 to the CLR version would as bad if not worse than learning a new language. At least when you are learning a new language you expect it to behave differently. The experience of the VB community is that they are trying to use their favorite language and finding out that is not at all what they are used to.