Looking for Python programmers--where to search?

[Alex Martelli]

"Eric Lee Green" <eric at estinc.com> wrote in message
news:39AD74A3.66696030 at estinc.com...
> 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

Yes, probably.  What we've always done in Cad.Lab (now think3) is CAD
programs; some of them do lots of database interaction (PDM & such),
but the interactions still came from a few big programs, not many small
ones, as a rule.  Plus, we always supported, as well as Unix, also non
Unix platforms where process startup was too costly to treat lightly (e.g.,
VMS), so we did not normally architect applications to spawn a large
number of processes, anyway.

> 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

"Theoretically" is right, at least for other kinds of programs, or database
applications that needed to work cross-platform rather than just on Unix.

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

I guess the latter issue is why Unix lost the desktop (to Macs and PCs) in
the early '90s...?-)

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

Well, yes; components are no "silver bullet" -- just a very useful way
to structure applications and systems.  But the trend is towards standard
ways for them to interact, that are partly self-defining (e.g., XML data
exchange with Schemas &tc); I find that these technological trends
help, in making it easier to have geographically distributed development
than it was the case a few years ago.


Alex