>The point is, there are many more circumstances where VFP does make sense. This is one of them and by itself proves the ignorance of your statement. You're looking from your own little perspective which has little to do with the world outside. VFP never played a significant role in the big corporate world and implying its dead because of its decline up there is silly. It is in the mom-and-pop applications where VFP still will be significantly present.
>
>"Ignorance"....hmmm, all this coming from someone who stated that VFP handles design patterns better than .NET because of the way it works with data.....from someone who openly asserted VFP developers' right to arrogance as the only enlightened ones when it comes to working with data.

Disprove the point, VFP is way more flexible as it can:
1. Use scripts stored in memo fields way easier than in .NET
2. Meta data stored in an executable in a natural way (embedded DBF)
3. Is not strongly typed, so you don't have to escape to reflection or .NEt generics.

You are the one not seeing the point here. Again disprove the points above. Yes, I'm arrogant enough to say that the average FOX-er knows more about data than the average .NET-er just because the latter probably had little exposure to the strenghts of VFP. You don't have to be einstein to see that. However you'll have to be ignorant to dismiss that.

>I don't say or imply that "VFP is dead" because I don't talk and think that way - you're putting words in my mouth. What I have been saying is that it's been on a downward trend for several years, and conversion projects continue to mount. Yes, a few go from VFP to Java/Oracle, but most go to .NET/SQL Server. Sure, VFP apps will continue to be present for mom-and-pop apps. The same could be said for VB6. Maybe even some Delphi and QuickBasic and Clarion applications. So what????

Indeed so, what? So what is the reason to say that you would do your client a disserve to start a new VFP project ???????

>Walter, this "best tool for the job" argument (as it's been presented here) isn't sharp.

Explain...

>Expecting it as the only appropriate response to every scenario has become an almost knee-jerk expectation. It reminds me of the ubiquitous question on employment honesty tests: "If you saw a co-worker stealing a dollar bill out of a cash register, would you immediately rat them out?" Those who respond with anything other than "yes" are potentially viewed as dishonest.

I don't see the analogy.

>Walter, I've worked for the feds, state govts, large companies, medium ones, and yes, small ones. I don't like to start making comparisons, but I'm guessing I probably have a little better breadth of experience than you - and a better concept of all the characteristics that go into the word "best".

Hmmm, lets see. Multinational trading, Education, Big insurance companies, Government, Justice, WHO, health care in asia, africa, europe and north america, but also local greenhouses, car shops, child day care and alternative health care. .... I think you'd better think twice in thinking you've got more breed of experience here...

>"Best" also includes business considerations - I know companies that have not won contracts ONLY because their products/services were specifically VFP-based.

Oh, I know, I know.... I've been fighting that battle for 15 years now on few occasions but always won. Ever since MS bought FPD to kill it. Every client has different business considerations. You asume upfront that the tool a product is written is an important factor to every client. How so, please explain? So, if I'm selling my mom and pop application to a client, does the client care about the tool it written in?? Also a client with significant VFP investments and its own VFP development team would not start anything new in VFP ?? In the same analogy, would they not start anything new in Cobol ??


>I'd said my two cents. You can have your numerous and diffuse mom-and-pop shops, and JR can have his QuickBooks app.

So what is your conclusion on your own statement?? After all that is what I was reacting on...

Kevin, for someone who claims to have more breadth of experience than me, you seem to have learned little about the world outside there. I've been there and seen how clients deal with these issues. Maybe things work a little different in pensylvania, but having business in europe, and north america including several states of the US, I can say that most of our clients do not care about the tool. They care about the product, sales and its support and additional services.

Are things different when you are doing contract work? Sure, because the decision is not up to you what and how to write. But for someone providing a complete product I don't see why the client should care that much.

A personal question, what is your highest education in the computer science field ??? What is your theoretical background??