>>I don't think it'll come as a surprise to anyone that I fully agree with everything you've said here. While in a perfect world, it'd be nice if VFP could be in the CLR arena without losing any of its current functionality, the world isn't perfect. If I need an application that needs to run under the CLR, I'll write it in VB.NET or C#. If I need to munge data under Win32, I'll write it in VFP.
>>
>
>>>I've said this before, but it bears repeating. Making VFP a CLR language makes it nothing more than a bad version of VB.NET and most certainly would kill the product.<<
>
>What makes you say that?
>
>Along the same lines we could think of VB.Net as a bad version of C#, (I think longtime VB people are already saying that) but that does not necessarily mean that VB.Net will die. I think VB.Net was created to accomodate VB programmers and bring them to the "latest and greatest" MS technology, and the same would be true if there was to be a .Net version of VFP. If you think about it, part of the appeal of the VFP Toolkit for .Net is the familiarity with the syntax, "feeling right at home" if you will.
>
>I'm not saying that VFP should be a .Net language just yet, (perhaps the transition would be more transparent to VFP folks already accostumed to OOP) I just don't think that VFP will die if it was made into a .Net language.
>
>Just my opinion,

J.,

At the risk of perhaps parroting Ed too much (which in and of itself may not be a bad thing< s >), what would be lost are the features that make VFP what it is. It is important to remember that it's the CLR that determines what features are available to a language. Currently, at least, these do not include things like a native file system.

Further, VB is a general purpose language and VFP most certainly is not. Remove the data manipulation functions from VFP and, yes it could be a general purpose language, but since it isn't designed to be one in the first place, it couldn't hope to be as good as a language that was designed to be that in the first place. That's why I say it would be a bad version of VB.

At the risk of starting a small firestorm here, I'll say that even giving the ability to produce both managed and unmanaged code would be of little, if any, benefit. I say this simply because of the above and why would I choose VFP over VB when producing a CLR compatible application? My familarity with VFP? IMV, that's not enough. I'd go for a tool designed from the bottom up for that purpose. Of course, it helps that I'm familar with VB (as well as a number of other languages), but even that isn't a compelling factor. Programming isn't about the language used. As Ed said, it's about problem solving and you go with the tool that's best designed to solve a particular problem. So if I need to munge data, I go with VFP. If, however, I don't, then I examine the problem, and make the determination of what tool is best suited for it.