Size problem

Mon Jan 13 13:59:00 GMT 2003

Erik Poupaert writes:
 > 
 > >> No, not at all. It's a perfectly reasonable way to construct an
 > >>application.
 > >>> How would he know that there were 20 executables? It's just a way of
 > >>> building an application.
 > 
 > Passing information between executables is a bit more difficult than passing
 > references (or primitives) within the same process; especially when they are
 > tightly coupled. You'd either have to pass things over the command line (cum
 > file system), or else you need to introduce a network protocol.
Where's the problem? A bunch of simple executables tied together with
a glue language is vey flexible and gives good separation, where the
GUI doesn't need to be integrated into every executable. For example,
you can have executables driven from a scripting language, or from a
GUI. Maybe from several different GUIs. I know it's not the Windows
Way, but so what? It's still sometimes a good way to work, especially
if you sometime need a way to automate things with scripts.
 > When it's needed to institute interprocess communication between tightly
 > coupled subsystems, I do it; otherwise, I stay clear of it. Therefore, these
 > typical windows applications with 20 forms or more, targetted at typical
 > windows users, would not necessarily benefit from being split into 20
 > executables.
Not necessarily, no. But it might. And simply insisting that there
is only one right way to do things doesn't help at all. There's more
than one way to do most things, and your tradeoffs may not be other
people's.
Andrew.