Couldn't agree more. I'm just starting up the learning curve in .net and doing it the way I did VFP - not trying to reinvent wheels but trying to leverage what others have discovered and focusing on learning the new environment by appying it to real business problems. ( Frameworks are the biggest bargain in our business. Adopting VFE early was definitely worth 500k to me. )

Learning Strataframe now. First concept was : business objects using objectified data and record objects ... and I'm finding that what I'm doing now looks like VFP-SQL server apps I write with the VFE framework. So many design concepts are the same, and the MicroFour guys get data, at least in terms of taking a lot of the strangeness out of it for Fox people who worked with objectified data in Fox.

And again, the part I'm really enjoying is all the stuff that is a pain in VFP that is wired in in .net ( UI and API ) , a million third part tools that have an extremely high ROI, a very interesting IDE in Visual Studio, 100,000 websites, books, forums etc ( kind of like getting into Fox when I did in the early days ) and a lot of excitement.

I'll always love the Fox - it's made me a lot of money and a lot of friends - but what got me into this whole geek thing a long time ago was the rush of learning new stuff and the excitement of a lot of mental energy coming from a lot of people to create something.


>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.