1 big or many little
cowhead at mac.com
Mon Sep 9 12:55:01 CDT 2002
> Whether it's delared as "local" or "static" or "scriptLocal" or
> else or simply called "bob", the important thing is the key role this
> variable type can play in simplifying code and encouraging code reuse.
> took me a while to get comfortable with them, but they've radically
> my code style.
Well, since we have "handler local" and "script local"....can't we have
a "stack local" ? That would solve the 'meshing globals' problem and
absolve the need for a rev 'player'.
"The savings in HD space for the 1 BIG method is laughable these days (I
just bought an 80 GB HD for $150) and the savings in RAM is rapidly
I believe that this kind of thinking can too easily lead one unwittingly
down the path of poor programming. It becomes easy to do inefficient
"quick-and-dirty" that works for a small program because the
are "covered" by all the available RAM and disk space. Through habit,
sloppy methods become the norm, and when it's time to do a big project
requiring utmost efficiency, we're at a serious disadvantage from not
learned the efficient methods on the small, easy programs.
Agreed, but remember, not all of us here are real 'programmers'. For
example, I am, if I'm anything, a scientist. So my priorities are
probably radically different from yours, and I can't really envision the
day when I will have a project requiring utmost efficiency in terms of
computer power. I know my code is often sloppy, but it gets MY job done
and thats how I measure my 'efficiency'. Also, if you follow your
argument to the logical extreme, you probably shouldn't be programming
in this big, bloated engine anyway, but rather using some crisp, lean,
lower level language. But we all know that, in the long run, that
probably turns out to be a lot less efficient. So just look in the
mirror and say to yourself, "A little slop is OK, and damn it, people
Thanks to all for your input on this thread. I'll have to mull it all
More information about the use-livecode