windows defender issues? & other AV issues?

[Curry Kenworthy]

Richard:

 > Everyone on the LC dev team is either a CS or advanced
 > mathematics graduate.
 > I'm more interested in those of us who do not hold a doctorate in CS

That's why I mentioned both - the same rules apply to everyone. Not just 
in the LC world either. Math, physics, gravity, good or bad coding 
habits, rain - apply to all.

And I have the same respect for all, PHD or GED, but neither gets a free 
buddy pass from the laws of our universe (or from myself, since I also 
notice those laws) on what works best.

 > when we do what should be considered the "right" thing
 > and still find performance impaired.

It usually WON'T be impaired in that case - consistently applying solid 
philosophy, plus not assuming that all other code has been done well, 
tends to avoid the problems; that's the point. Key: solid philosophy, 
disciplined habits.

 > I'm less interested in casting judgment on code I haven't read
 > written by other people than just making the code I'm responsible
 > for writing perform well.

It's not casting an emotional moral judgment (although come to think of 
it, scribbling horns on pics of offenders would be pretty fun). :D

But what I actually do is train and encourage people to strive for good 
coding habits.

To me it's simply - what else would anyone expect?

You get the cake you bake. The recipe you follow. If you put in 50 eggs 
or drop a cigarette into the batter, you get that too. Your actions 
dictate the result.

That may seem extreme examples, but so is constant disk access or other 
things that use resources too frequently or at a bad tim3. It's not 
cool. Nor something that we should just wait until it pops up, like 
whack-a-mole. That why our brains have pattern matching and 
philosophical features built in. Develop good habits. Anticipate 
possible issues. It's one of the many things people should have in mind 
to watch out for from the START, at least in their own code that they 
write themselves.

DB, flat file, web; doesn't matter. Nor only with this particular issue 
of disk access. Either way, people shouldn't just code things however 
the mood (or the sprint) takes them. Code carefully, organize well, try 
to anticipate what could go wrong as you type, think ahead, and learn 
from every mistake you make, take it to heart. The more problems that 
can be avoided mentally BEFORE they are written, the fewer to spend 
limited resources fixing. We can't eliminate bugs, but we can reduce a 
certain % with very little overhead on coding mental load, so it's a 
huge win.

If people don't code carefully with good habits, you'll get exactly the 
result that you created, sometimes you lucky anyway, and sometimes not. 
I like to help people start developing those good habits and turn around 
any bad ones.

I can often "smell" or calculate a very rough likely/not assessment that 
problems exist in other code by symptoms and logic; it's not by chance 
that I'm very often correct when i show up and start harping on 
something that triggers people. Ha ha. :)

 > And with modern conventions trending toward auto-saving vs the
 > older explicit user-driven saves, some of the most well-written
 > apps write to disk more frequently than ever before.

There are also a lot of badly-written apps, even from big companies. 
Lousy code and sloppy work is fairly epidemic, tons of bad examples to 
potentially mislead the unwary CS student or PT hobbyist. I'm especially 
SMH when major websites or apps mess up their CORE features (up to and 
including financial ones) while undergoing mobile redesigns. Losing 
sight of the most important things. This is not an era of exemplary code 
in the world.

Auto saves not being triggered by the user puts us more in control, 
right? That's a good thing too. We have all the opportunity, and also 
responsibility to do it well. Not 10 times per second of course, to 
exaggerate again (although you never know) but when something needs to 
happen, there are plenty of things we can do to make it smooth and time 
it smart so the user doesn't get slapped in the face. If the user must 
be interrupted, give it a visual indicator. Actually quite simple to 
make apps very responsive, at least until the OS gets in the way and 
decides now it's time for something completely different.

Believe me, this is not very difficult to get right as far as its in 
your hands, and the rest, from OS and other apps, will usually not take 
things down too much further. People at all levels can understand being 
careful not to interrupt what the user is doing, and not calling 
expensive features too often.

 > a lot of lstat and open calls apparently looking for, and not
 > finding, the App Overview stack file

Very interesting. Glad you found that. More examples of things 
that...never mind! :D Hope you keep poking around.

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/