>>>if you say cost could only be the difference and they would both take the same time, why different cost?
>>
>>It is only a possibility. A .NET app could very well cost less than a VFP app. Depends on the developer and his capabilities.
>>
>>Aside from that, one developer is building an application in a dead-end language that has a dwindling support capability. The other is developing in a mainstream well supported environment. What would you pick?
>
>Hmmm, I don't see it that way.. Why would support in a dead-end-language be less than in another language. As long as you've got well trained VFP developpers, why would your support be less?

One important feature of VFP is no new bugs. It's as stable as it will ever be, it's mature, there aren't many hairpullers left, and whoever is maintaining a VFP app doesn't have to fight the uphill battle of adjusting to new features, new bugs, and new ways of doing the same things. And the experience isn't going obsolete - what techniques dropped off the list of best practices, they did so long ago. There's a slim chance that a viable VFP app nowadays will have to be rewritten a lot just because of bad technique which somehow clashes with the way things are done today - that has already happened, and was done. You don't have to tie the dog, untie the dog, give water to dog, start over... that part of the work is finished.

This is, of course, a probability. The probability that someone, who is less than a professional, will get to maintain an app written by someone less than a professional is about 81% (by Sturgeon's law), but that's language independent.