SNIP

>Seriously, VFP has a role and can succeed. While it may not have wide business acceptance, it does not diminish the technical abilities of the product. The business hurdles are at times, tough to overcome. If you can clear the hurdles and you can make a technical go of it, you cannot fault the use of VFP. At the same time, you cannot fault developers who cannot clear the business hurdles and have decided to move on..
SNIP

The above paragraph correctly sums up my experience and the experiences of others I know. VFP is often the best tool for the job, but sometimes the best tool is not chosen due to little or no business acceptance in the corporate world. Othertimes it is accepted (or the client does not care what the product is written in) and the developer is able to provide the most cost-effective and efficient means of meeting business requirements utilizing VFP.
I know of a few developers that have already left VFP and not because it is not the preferred tool, but because they are tired of justifying its use to clients that shouldn't care less about the tool but only in meeting business requirements. These developers learned primarily VB on the side until they were comfortable use in place of VFP. Now they have to learn VB.NET to be competitive...