>>>>I do understand your arguments, all valid.
>>>>
>>>>Let me put it an other way with a metaphor.
>>>>
>>>>Imagine you own a cute renaissance manoir and your neighbor just built a brand-new palace, top energy efficient, very comfortable, build up with concrete, fiber glass and carbon, all 'modern' building techniques.
>>>>
>>>>Your manoir is not so comfortable but hey, you've spent weeks of your spare time to revamp it, have nice trees grow around it, etc. Your family and you feel at home in there.
>>>>But still you fear energy prices will go up and up to prices your budget can't afford.
>>>>
>>>>What do you do ?
>>>>- Build your own palace in the park then demolish your manoir ?
>>>> Nope, you don't have budget for both maintaining the manoir AND build a new palace, since you need to live in the manoir meanwhile
>>>>- Maintain your manoir with concrete and fiber glass ?
>>>> Nope again, you would loose the spirit and the charm
>>>>
>>>>So you wait until a solution shows up.
>>>>The someone drops in and tell you :
>>>>"Hey, wait a minute, we're just working on a new material that can fit with ancient buildings and solve your thermal isolation problem"
>>>>
>>>>At first you don't believe him.
>>>>
>>>>Two years later you see they are able to isolate a small ancient window. Not good enough for the whole manoir but fair enough to wait for completion.
>>>>etc.
>>>>
>>>>I see many VFP dev. and editors somewhat in this situation.
>>>>
>>>>Many have 50-100 man-years of VFP code.
>>>>Unless someone found it, no magic wand exist to convert that into .net / java / php code in less than the very same investment.
>>>>This is economically not viable.for the very simple reason that no client will ever pay for that since it does not bring HIM any additional value.
>>>>
>>>I see many clients paying to convert from VFP to other platforms. I see no clients paying to convert from anything to VFP.
>>
>>I don't see any requests to convert anything to COBOL either yet there is a ton of COBOL code still running. I'm willing to bet that there is no urgency for that code to be ported to .NET.
>
>COBOL is still a viable language.


Just like VFP in the right circumstances.


Many compilers are still supported including .NET versions.
>
>>
>>My wife is working on a application to be used on a factory floor. Guess what? They wanted it in *cough* Access *cough*!! There's another product that I'm sure filled the "mom and pop" business with no need to jump to .NET
>
>Access is still viable and supported. Access2010 shipped with Office 2010.
>
>VFP died at 9.0.

And VFP is a way better tool than Access ever could be. What a piece of CRAP. I curse Access every time I had to use it. I say "had to" because I'll never go there again.

>
>
>>
>>
>>>
>>>I'm in process of converting my VFP retail applications to .NET. Since my aps all use SQL Server as the database this is fairly easy. I will not start a new VFP application - I think that is a disservice to a client at this time.
>>>
>>>
>>>>So let's wait and support these courageous guys working on our windows ; old fashioned but so charming !