>It is now possible to write VFP on the CLR: the IronPython project is working on the 4th beta. In fact, Microsoft is hiring people to port dynamic languages to the CLR, building on the work with IronPython: http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038
>
>With that in mind, I wrote Milind Lele (Milind.Lele "at" microsoft.com), the new VFP Product Manager, as I had written Ken Levy when he was in that position, lobbying for VFP's inclusion in the list of languages to be ported. As I expressed it to Milind, while VFP's features are in the process of being ported to Visual Studio, there is a business benefit to MS to have VFP continue to lead the way in RAD data-oriented development. Not to mention the benefit to those of us whose business model is based on having that kind of development environment available.
>
>Milind's response was straight-forward: "Current plans for the future of VFP are what we have announced in the VFP roadmap and we will periodically update the plans. How these plans change will be driven by feedback similar to what you have written."
>
>So if you want VFP to have the best of both worlds, now would be a good time to let Milind know. It's no longer technologically infeasible: it's only a matter of resources.
>
>Hank

Hi Hank,

Once we are able to access all .NET classes from VFP there may not be that many advantages to VFP being based on the CLR. Perhaps we would not lose the local data engine after LINQ is implemented or macros once the CLR supports dynamic languages, but we would probably lose performace and the wonderful way of doing things the VFP way.

Once MS accepts (to itself only, of course) that a local data engine and a dynamic language are "good ideas" it is a sure thing that VFP's key advantages will live on in many products. The current roadmap may actually be pretty good for us.

Alex