Hi Jim,

>Hi Herman,
>
>It REALLY is all about personal opinion...

Yes I know that exactly. It is PERSONAL. That's why I said I never DEBATE ANYONE ABOUT ANYTHING.


>>Hi Walter,
>>

>>I never try to involve in a debate with anyone about anything. But I see that we are in the same POV in this M. things. It does ugly :-)
>
>I don't mind "m." nearly as much as I absolutely HATE lcMyVariable or llRet. These are REAL ugliness!
>>
>>I just want to say one thing. If I REALY DO NEED SPEED DESPERATELY, I will go to C/C++ or even Assembly (of course with hands optimization) for that matter.
>
>So C/C++ is prettier than VFP???? < s >
Of course not. That's why I choose VFP and I stick to VFP *bg*. It's just the sake of the SPEED argument.

>By the way... with processors doing 2ghz - 3+ghz, these kinds of issues are VERY trivial compared to the cost (in time) of actual I/O. There is where people need to concentrate their performance efforts, in my humble opinion.
>

For computation thing, going even further than 2 Ghz, with C/C++ will always the BIG WINNER! There are more optimization things that available in C/C++. i.e: using MMX, SSE, or SSE2 or maybe with the upcoming newer instruction. That is direct PROCESSOR optimization. And unfortunately this is unavailable in Higher Level Languange.

>Jim
>>
>>>
>>>Number 1, my favourate lets me keep writing code without the ugly use of m. and only in rare occasions where I cannot be sure of having a field name in a selected table, I´ll use the m. argument. As for the speed argument, it really only is applicable in long CPU intensive jobs where a large field count table is selected. I´d have difficulty in naming one case I´ve ever programmed in my carreer.
>>>
>>>Bottom line, you can write good and solid code with or without using m. . No matter the argument you´re not going to convince the well experienced VFP developper to change his standpoint on this. It is non productive.
>>>
>>>My 0.02 eurocents
>>
>>Regards

Regards