>
>To the other comments, I want to add that VFP treats variables as an interpreter does, not as a compiler. This is not serious in practice, but it does have two drawbacks:

That's because VFP is interpreted.

>
>1) Often you only get an error message at runtime. It helps to develop better programs if errors appear already when you compile a program.

Can you provide an example?

>
>2) Since VFP has to loop up variables in its table of variables, working with variables is slower than with a "real" compiler.

Even "real" compilers have to look up the variable.

>
>3) The fact that all variables are of type "variant" also both makes the program slower, and can produce errors at run-time (type mismatch).

If you are getting this freqently, it's not a fault of VFP, but of the programmer. Better care should be taken to initialize the variables. Good naming practices help here.

>
>Some of these things, I think, have been changed in VFP 7 - specifically, I understand that you can specify the type of a variable.

No. That has not changed. VFP7 has what is called "strict typing", which, IMO, is poorly named. In this case, it really isn't strict typing. There is simply a way to define parameter types for methods in COM servers.