Global in multiple files

[Alex Martelli]

"Roman Suzi" <rnd at onego.ru> writes:
    ...
> >There is a serious risk in over-designing systems "because
> >one day it might be handy".  Yeah, right, but meanwhile you're
> >paying the price of complexity *RIGHT NOW*!-)
> 
> I always try to choose more flexible way as long as
> it doesn't add to complexity. When it is style of

If it adds NO complexity, why, sure.  It just
doesn't work that way _most often_, though.  The
natural temptation of the battle-scarred designer
is to overdesign "just in case" -- because the
hundred times where simple design had to be extended
later apparently burn themselves in our neural
circuits more than the thousand times where rich
and complex design just didn't pull its weight
and never really provided any added value.


> >"Do the simplest thing that could possibly work", because
> >"you ain't gonna need it" (where "it" is the rich, complex,
> >over-engineered, over-designed very general solution:-).
> 
> That is why Microsoft systems still have those funny
> A:, B:, C: letters before file paths ;-)

Nope, this has absolutely nothing to do with it.  Backwards
compatibility with externally-visible interfaces to previous
releases of your software (and older software you choose
to be similar/compatible to: CP/M, in Microsoft's case) are 
(as should be obvious -- I'm amazed I have to point this out)
a completely different issue.

Want to see Microsoft-based examples of over-design versus
simplicity?  Just look at the sheer amount of "reserved,
must be 0" parameters in their Win32 API's.  By far most
of those parameters have been mandatory zeros for close
to ten years now -- and meanwhile the places that would
have needed extra options didn't have them, so we have a
zillion cases of UglyMultiWordNameEx2.  Unix syscalls are
spare and functional, and have withstood the test of time
much more effectively than kernel-Win32 API's (despite
the notorious "I should have spelled 'creat' with an e"
admission of a design error by Thompson:-).

But, again, the issue of externally-exposed interfaces
is quite different from that of implementation architecture.
When you publish an interface, if your program meets with
any success, that interface has to stay forever.  When
you make a design choice regarding your implementation,
you're NOT etching anything into stone -- and that is
what we're talking about here: whether to use a simple
global list, to do the job of a simple global list, OR
overdesign and overarchitect a whole subsystem to take
the place of the simple, obvious approach.

Want more examples?  Of course they'll again be from
the real of externally-exposed interfaces, because that
is where it's easier to share them:-), but that's OK,
since if some simple architecture works well in a
relatively unfavourable case (externally exposed itf)
it will work even better in favourable ones (internal
implementation choices).  How does Python let you know
what built-in modules it has?  A simple global list,
sys.builtin_module_names.  How does it let you know
what arguments your program was called with?  A simple
global list, sys.argv.  How does it let you know AND
AFFECT where modules will be imported from?  A simple
global list, sys.path.  How does it let you know what
modules have been imported os far?  A simple global
_dictionary_ (aha, a variant!-), sys.modules.

Simplicity WORKS WELL.  Simplicity is the backbone of
Python, what really makes it great -- wonderful to
use, powerful AND easy, peerless.  Want to learn to
design programs really well?  You could do worse than
to study what Guido and friends did in Python.  You
will find the small errors and debatable decisions,
you will find the huge numbers of "just right" design
choices, large and small.  Notice how many times those
"just right" choices end up delivering *SIMPLICITY*
over and over again...!-)


> Because "right yesterday" 640K was enough for everything.

Furthermore, the choice of drive-letters for file paths,
and the issue of amount of addressable memory, are also
quite obviously independent.  As, again, this is utterly
obvious, I do not understand why you appear to assert
causal dependency between these design choices ('Because'?!).

> >See http://c2.com/cgi/wiki?YouArentGonnaNeedIt ...

I reiterate this advice... the Wiki is really a good
place to see these issues discussed -- as open to all
sides as a newsgroup, but building up to more permanent
documents... but not so permanent that you can't always
enhance them (be it only with your questions and open
issues).


Alex