many small or 1 big?

[miscdas at boxfrog.com]

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 
laughable." 

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
> Japan 
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution