Hi Bill,

>>>there's nothing that I can do in VFP that I can't do in .NET
>
>Yes, that's certainly true, but the question might not be can you do it? but rather how efficiently and quickly can you do it?

Well, yes and no. True you can write a data query in fox with a single line of code that takes 10 in .NET. But I also don't think that that's a fair comparison, because a) you never actually write those 10 lines of code in .NET except maybe once in a data access layer and b) those 10 lines of code are a heck of a lot more flexible than what you can do in VFP. In fact if you compare apples to apples with that SQL statement and you connect to SQL Server that 1 line of code gets to be more like 5 or potentially more if figure setting up remote views.

VFP does a few things very well no doubt and easy data access and post query manipulation of data are two that are the big standouts that aren't easily duplicated. However, if you work with SQL Server in FoxPro and with Business objects (as I typically do) some of those advantages actually go away and when you compare the code you write with business objects in VFP and .NET I find the code is nearly identical and equeally lean (and actually more efficient than 'raw Fox' code).

There's no doubt there are trade offs, but I'll gladly argue that for the actual applications I do in .NET these days I write LESS code than I write in FoxPro and I spend significantly LESS time trying to figure out arcane API calls to provide some functionality missing in VFP (especially in desktop apps - not so much for Web apps). The real time killer for me in VFP is not the main application but the edge cases - trying to get the UI to do something that VFP doesn't do well, getting an ActiveX control to behave properly or to make system calls to APIs that VFP can't directly connect to without mental acrobatics. Those things are time killers that individually often can eat a half a day by themselves.

Verbosity by itself also is not always bad. Don't forget debugging, discoverability and compile time type checking all of which are over all performance boosters (at least for me) and make it easier to produce more solid code even before you run the code for the first time.

I'm not trying to take aways from VFP. I know VFP way better than i know .NET and probably ever will for that matter, because the VFP feature set I can actually manage in my head. But if I compare what it takes to build apps it's certainly no slower doing so in .NET now although I will definitely admit it takes some time to get to that point. But then again, today learning any new tool/language is not going to be an quick ramp up.



+++ Rick ---

>
>When DBase hit the market, I was astounded to see that I could do in 3 lines what it took me 3 pages of code to do in COBOL, and I was an instant convert.
>
>As I move to .NET, I'm finding the reverse... not anything like the same magniturde, but in that direction.
>
>I stayed up nights and moved from COBOL to DBASE in a week- I couldn't wait.
>
>Ditto from DBASE to Fox - it was a no brainer!
>
>In this case, it's a forced march and it is definitely not a pleasant journey.
>
>Our group services small business who have not expressed any immediate need for the powers in .NET. that are not available in VFP, so we can't offer any real benefits for the swap, at least for now.
>
>When I took clients from COBOL to DBASE, I could say.. "Hey that mainframe that costs you $4K a month will disappear, so will 5 programmers and you'll be state of the art."
>
>Going for VFP to .NET I now can say. "Hey that program that would have taken 1 day to write will take 1.5 days- but.. you'll be state of the art!"
>
>Sure, we can sell it, but it's an intangible benefit at best.