I am resonably sure about your description of a team of 1. I've run into people who argue along the same lines as Walter everytime a new paradigm comes across that runs counter to the tool that the desenter uses most of the time.

Windows 3.1 vs. DOS was an interesting time. I worked with a guy who spent his free time sending hate mail to Gates describing what an obomination he thought Windows was.

Personally, the biggest difference I've encountered between VFP developers, .net devs, java devs, etc., is the team concept. And knowing what's available to accomplish goals, such as meta data, design patterns.

And several of the people I work with have indeed with with Foxpro of some flavor. And I've never heard any of them make a comment about missing a feature of Foxpro while they work in another language.

If anything I've witness several instances of ex-VFP people attempting to similate into development groups of other languages and having a tough time of it. They found some bizarre way of implementing some feature into their VFP app and try to get the Java/.net team to implement the same way.

>Yawn.
>
>Walter, last year you kept criticizing my statement about how stored procs can be flexibile - NULL handling was part of your argument. Well, I demonstrated to everyone how you can use sprocs for updates that handle NULLs as well as "change-tracking". I know that a few people wound up using what I posted.
>
>
>I have zero interest in debating someone who states the following:
>
>I'm convinced we should be so arrogant in proclaiming that we are one of the few who knows how to handle data. From what I've seen in the .NET world (but also the java world) and also from the .NET experts here, there really is a lack of realism what the power of data is and how data should be done.
>
>Some of your notions, specifically embedded meta-data in EXEs, are more hacked-out solutions, and hardly scalable (not only in the obvious sense, but also for the size of the development teamm). I really get the feeling from many of your posts that you often work on very small teams, or teams of one.
>
>Now...if someone else wants to jump in with a relevant example that can be realistically compared, I'll consider a comparison.