With the risk of saying loudly things that should be said quietly, I would like to share the following :

There is a lot of talk recently as to whether VFP should continue as a separate product or incorporated with one way or another into .NET. All these debates which have to do with the future of the tool we use in our every day development, really concerns me as it concerns every VFP developer.

I am using VFP since 2.5, and I am a strong advocate of the tool. Because I am the decision maker of the company I work for, I have pushed for an MSDN subscription, mainly for getting Fox and partially for testing with the other tools that MSDN includes. If it wasn’t fox I don’t think I would have chosen an MSDN subscription, or generally talking if it wasn’t fox I wouldn’t have been involved or made my company get involved so deeply with the other Microsoft Tools and technologies. This is because we are not a software house but we rather use data tools for doing our departmental jobs – these departments include accounting, transportation, logistics – and we had many choices and have developed programs with tools such as powerbuilder, cobol and other proprietary tools.

On the other hand based on all these talkings, I was thinking why am I preferring VFP for developing. Is it because I know it very well?, No, because I know many other languages (like VB), and I am flexible enough to learn new things. Is it because of some romantic tendency of staying with a tool with a so great community, well partially this is true but this is not the main reason because at first we are programmers and we have to make a living. Is it because I like the syntax? Well syntax is something you sometimes get sticked to and it is true that I dislike VB syntax, but I wouldn’t change or prefer a tool just for the syntax.

At last why we like fox? Very simply because she enable us to do things easy, with speed and flexibility that other tools do not provide. This means that if a tool any tool, will provide the same functionality that fox give us I wouldn’t have any hesitation to change. And when I say the same functionality I mean build into the tool without any interoperability layers…
For start the following are some of the must functionalities that I think make the tool unique :
- local data engine with sql manipulation language build in
- macros
- command window
- form buffering

If MS could give us such a tool, I wouldn’t bother if this tool is named VB.Net, or Data tools for .NET. I would not bother if the local data engine is named dbf any more or to keep backward compatibility, in fact I think Micrsoft is right – and is right for us as well – if for marketing reasons it kills these names. But I repeat, all these if and only if they give us the same functionality that we now have and especially to these that VFP shines like buffering and cursors, data manipulation language inherent in the tool with out passing the sql statement as string etc, (and not just marketing, like when Microsoft says: VFP is fully compatible with .Net when in reality is not).

I am quoting Ken Levy who seems to showing the same direction :

>Every time we review this topic over the past 3+ years, we the VFP team and others
>at Microsoft come to the same conclusion. The next versions of Visual Studio
>(Whidbey and Orcas) will have more and more VFP-like features in it for data
>handling and other. The VB team and the VS Data team have VFP 8.0 on their >machines and I woul dsay they know and understand the great features in VFP more
>than ever. This goes to further back what you summarize here.

But I don’t think this is enough. It is not enough to have, informally Fox installed on the machines if some developers, to make this transition happen . Microsoft should commit – and have a plan for it - that will bring the functionality that we the Fox community think is important to be incorporated as enhancements in .NET. This said, the transition should be done smoothly, and until the main functionality gets into .Net new versions of VFp should occur.
I think we have to start talking what is needed to be kept in such a tool and make Microsoft pass it to the new versions of .NET.

What do you think ?

Thank you
Dimitris