>A macro, or dynamic execution -- in VFP we have execscript() and can also compile an fxp (which can be very important in dynamic web sites, e.g.).
>
>Dynamic means more than that, though: it also means the ability to instantiate a class in the IDE, in the command window, and test it out. It means the ability to interrogate and modify objects in design mode, and while running in the IDE. It means the ability to run without compiling.

In other words, it means a (perhaps efficient) interpreted or semi interpreted language.

>As for internet apps: unless you are doing hugh enterprise apps, Web Connection and possibly ActiveVFP will give you want you want. Creating a REST web service in either is trivial, and in either you can compile your VFP application right into the web framework, so there is no COM overhead in the calls to your application being served through the web. I'm sure the same is true of the other VFP web products, each of which has its good points and its adherents.

Thanks for the clarification. I don't do huge enterprise apps, actually.

>As for data centric functionality: we've already been told that VB.Net and C# will be getting more of this. And to some extent that's overrated, although the gyrations needed in .Net today, which are lessened in VS2005, are inexcusable. Nevertheless, something like Mere Mortals .Net (MM.Net) takes the pain away, so whether that gets added is pretty irrelevant to me, as there are so many good things (as in "ouch, another .Net idiosyncracy -- good thing Kevin found it and worked around it") in MM.Net that I'd be using it even if data centric functionality were present in VS.Net.

I looked at .NET for a couple of months as soon as I found out about it and was turned off by its cumbersomness compared with VFP.

Thank you for taking the time to give me a good explanation.

Alex