>Ed
>
>I've lurked on here for a few years and this is my first UT posting (tarah!).

I'm not sure if congratulations or condolences are in order... < g >

>
>In this instance I think you are vividly illustrating the difference between programmers and marketing types. You want truth and objectivity. Marketing types want _success_in_the_marketplace_.
>

I'm not a fan of marketroids in general, but I'm greedy - I want both.

>.NET is just a marketing buzz-phrase, nothing more. Sure, at the end of the day clients want results at a realistic price. And this is what we can do well with vfp. But how often do we get locked out of a job because someone else says they can do the job with M$'s 'tool-of-the-moment' which must therefore, "by definition", _be_ better_ (oh, and by the way, it'll cost you more). We live in a world of hype and if we (VFP) don't get dirty with the rest the future for vfp is limited (great tool though it is).
>

dotNet is, to me at least, much more than a buzz-phrase; it's an overall philosophical approach to a platform-independent implementation built around a central virtual machine engine and a hierarchical service space that can be expanded and extended by the developer. That virtual environment is not identical to the Win32 platform, and TPTB who are in a position to know what would be required to port the VFP environment to the managed code arena have repeatedly stated that we'd have to give up too much of what VFP is valued for in order to make the VFP interpreter run in managed code; I can easily imagine the costs associated with running through several layers of interpretation, and that there'd be losses in performance where VFP leverages the Win32 platform's characteristics and capabilities directly now. Call me stupid, but I believe that Ken, Ricardo, Calvin et al know more about what's inside the box than I do by a wide margin, and I trust them enough to take them at their word. What makes VFP a valuable tool to me is not simple syntax (it'd be easy enough to kludge up a parser and compiler based on the native xBASE syntax as long as we were willing to sacrifice that portion of the language that talks about things that simply do not have a direct parallel in dotNetLand, and if all you want to do is to have an xBASE syntax-derived CLR language without VFP's unique qualities, that's a far less daunting task than to port all of VFP capabilities into managed code. Something about trying to pour a gallon of capability into a shotglass of syntax...

So you need to ask yourself if you want an xBASE-flavored managed code implementation without the native file system, or do you want all of VFP inside of dotNet? If you want all of VFP inside of dotNet, then why is there a need for a VFP flavor to it?