Looking for Python programmers--where to search?

[Eric Lee Green]

Alex Martelli wrote:
> "Eric Lee Green" <eric at estinc.com> wrote in message
> > A few years ago I would have agreed with you. The problem is that projects
> are
> > becoming more and more complex, and as they become more complex,
> interactions
> > become more complex. A typical project ten years ago had one component
> type --
> 
> Funny, the trend as I've noticed it is exactly the other way around -- our
> company has been opening development labs in a lot of sites around the
> world, to maximize our chances of getting the best people on board even
> if they want to live far from our main location, and my experience is that
> the technology's progress is making it easier, not harder, to handle.  That
> little word 'component' is the key. 

Hmm... I suspect that we may have come from different worlds. Everything in
Unix has theoretically been a "component" forever ("many small programs
chained together"). In my experience, until recently, Unix database
applications consisted of a) a menu program that invoked individual programs,
and b) the individual programs themselves. The individual programs themselves
generally did one thing, and one thing only, e.g., edit a customer
demographics screen, and if the program allowed you to pull up another screen,
what usually happened behind the scenes was that another program was being
called with a record ID to display as its command line parameter, and the
current program put to sleep until that other program returned. 

The move to GUI design changed this paradigm somewhat, in that monolithic
programs became not only possible but, due to the rather idiotic design of
currently-extant windowing toolkits, necessary. However, Unix database
applications did not really start moving to GUI interfaces en-masse until the
mid 90's. 

While the move to component design is certainly preferable to monolithic
programs, there is still the problem of adequately defining the components and
their interactions. And some "components" get mightily large, e.g. one
component that I am currently writing pulls in some dozen-odd modules and
deals with nearly a dozen individual object classes. Of course, this component
is sort of the whole point of the entire application, i.e., it is the single
most complex component in the system, and most components in the system are
much smaller and cleaner, but the interactions are still there. 

-- 
Eric Lee Green                         eric at estinc.com
Software Engineer                      "The BRU Guys"
Enhanced Software Technologies, Inc.   http://www.estinc.com/
(602) 470-1115 voice                   (602) 470-1116 fax