>>>So, Knuth supports a 12%. I'm certain a 227% would be a big deal, especially adding the safety factor.
>
>There's no doubt that if selected cursor has 254 fields, mdot makes a difference. However, if that 227% difference is measured in microseconds in the GUI of an actual app, perhaps we can agree that people are entitled to say "so what"

They can say so what all they want. That doesn't give them the right to dismiss the fact that it is there or be harassing me about it. My new code doesn't crash and is faster. I'll take it, while the peons say so what.

In case you have missed it, everything I write some dumb peon has to argue against. Every time. You think that is healthy? The guy is a peon and has nothing better to do than attempt to make me look stupid because he's a jerk.

The Sun is not drawn across the sky on a golden chariot. So what. The point is, mdot can easily give me a 12% improvement for FREE. That is completely acceptable to the hero of some of these nitwits, Knuth. It is built into FoxPro. Only an idiot would pass up free simply for not liking how it looks. Further, such idiots would demand I never add mdot to code they get from me. That is Nazi-esque.

Having written and given code for others to use, I do not force them to change their naming conventions to suit me. I recognize they may have named a field lnx and I cannot take the risk that my use of lnX crashes. Then I look stupid, not the user. None of my code has come back with a complaint of crashes no matter where it was used. I worked with Drew Speedie on MaxFrame. You think he would have accepted a crash which was easily prevented? A pound of cure is good enough to the peons.

" or to refuse to remedy VFP code that frequently is years or decades old. If we are scientists then we never treat hypotheses as universal truths, and experience/evidence that contradicts our hypotheses is the most valuable, never to be personalized or scorned.

Ah, but there are indeed many universal truths, especially in a limited scope. Ignoring such results in a big waste of time. Is there one instance where mdot used properly is bad? Nope. So that's all that needs to be said. I am always ready to be proven wrong, but this issue has never been disproven. Saying I don't like it, or So what, is not science.

It is my scientific approach that is being scorned. The non-scientific approach certainly can be scorned. If the code is very old, well guess what, if it is in production and being supported, then darn tootin I will add the best science to the job. That is the professional and scientific thing to do. Anything less is to be scorned.

>
>FWIW, using private variables rather than passing parameters to functions also makes a big difference, at the cost of legibility/familiarity. Do you pass parameters? At some point, perfect becomes the enemy of good.

I always pass parameters, because that is not perfect, it is better than what is honestly barely good enough among humans. You forget the cost of encapsulation. Something can affect the private variables leaving the calling code in a huge mess or multiple patients dying.

>
>Also FWIW, a defining benefit of VFP used to be its auto-spanning to disk, meaning you could have resultsets that exceed utilized or even available memory in days when a growing .NET dataset could bring a machine to its knees. I was taunted on this point for years by a certain fellow in the UT forums. I never took it personally- just as well, because time went by and machines had more memory than VFP could utilize anyway. Then came devices that blurred the difference between dynamic memory and storage. Along the way, "web is best" hypotheses eliminated the concept of local datasets, though it's back now on devices unlikely to be stressed by any sensible dataset.

I have been conscious of connection resiliency a long time. We built it into MaxFrame. It is only recently becoming an issue with Azure, so web is not always best, but it is improving.

>
>Certainly I agree that development remains an expensive cottage artisan industry rather than the automated more efficient models that usually result from technology, but that has been to the financial benefit of many here and change is a'coming.

This expensive "artisan" is why business refuses to upgrade, living on legacy systems that have ZERO standards or good practices. The practices are not even good enough, but they don't know the difference between crap, good enough, good and I've never seen perfect. Change has taken way too long.

We had a bug the other day. One of us compiled an exe, and someone reported a file missing error. The earlier programmer never knew he was doing something incorrect. It was just his habit. REPORT FORM 'something' does not get included by the project manager. Remove the single quotes, and fixed. A single programmer can operate the way a team does, but has no training. I have seen way too many without training somehow getting jobs.