many small or 1 big?

[mark mitchell]

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
Japan