many small or 1 big?
miscdas at boxfrog.com
miscdas at boxfrog.com
Sun Sep 8 13:54:00 CDT 2002
This is OT from your request, but I think worth a philosophical comment.
"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 becoming
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 inefficiencies
are "covered" by all the available RAM and disk space. Through habit, these
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 having
learned the efficient methods on the small, easy programs.
In a more general sense, it's like saying that the little things in life
don't matter, when in fact, they really do.
mark mitchell writes:
> I wonder if I might get the lists input on an overall design question.
> I've been making dozens of little applications. This comes from the
> hypercard mindset, wherein you have a single player and then you can have
> all the separate stacks you want. The problem with revolution was that
> stacks alone did not run so well without the development environment fired
> up. So as I made stacks, I converted them to standalones. This was
> working fine, but I had envisioned that I would one day make a single
> "table of contents" app, that could be used to organize, explain and
> launch all the little apps. As I went along however, I realized I
> sometimes had 4 or 5 of these little apps running, and they must each be
> using an identical engine and wasn't that silly when they could all be
> using the same? So I made a single 'table of contents' standalone and
> stuck all the former app data stacks in it. But now I'm not sure which
> was really better, this 1 big, or the previous many little?
> 1 Big conserves ram, as it only loads one engine, but now (and I'm putting
> my foot in my mouth here) I really DO have to worry about my globals
> meshing, don't I? With many little apps, I could use the same global
> names for each with narry a worry or care. Also, many littles seems like
> a nice fail-safe. If something goes wrong with one, the others are nice
> and isolated. This is not so important for me now, but in the future I
> may try to sell or license this package, and such a fail-safe would be
> nice in that event. I mean, if I was programming for the space-shuttle, I
> would definitely go with many littles. 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 becoming laughable. Many littles also
> allows you to use Apple's DOC to switch between the apps, which can be
> nice. So what to do? 1 big with it's globals headaches and less safety,
> or many littles which sometimes seems silly?
> Thanks to all for any input on this,
> mark mitchell
> use-revolution mailing list
> use-revolution at lists.runrev.com
More information about the use-livecode