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/
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
