Python component model

[Kay Schluehr]

val bykoski wrote:
> Peter Wang wrote:
> > Edward,
> >
> > This isn't in response to any specific one of the 100+ posts on this
> > thread, but I justed wanted to encourage you to continue your
> > investigation into Python component models and maybe looking for some
> > common ground between them.  Frequently the individual developers are
> > too heads-down on working on their own things to do a broad survey, so
> > I think this would be very useful indeed.
> >
> > I wouldn't have felt it necessary to post this except for the large
> > number of posts along the lines of "foo.dict is introspective enough
> > for me!".  I think you might have an easier time evangelizing the
> > principle of component-oriented programming (or "event-based", or
> > "reactive", or whatever) if you separated it from the notions of RAD UI
> > development.  There is a very large difference between writing
> > components and writing objects, and it seems that most people arguing
> > "python doesn't need components" don't see this distinction.
> >
> > For me, it's the difference between writing "live" objects and "dead"
> > objects.  Live objects not only encapsulate implementations of an
> > interface with some state, but they also encapsulate handling of
> > events, i.e. responses to changes in their environment.  Dead objects
> > have methods but there has to be a function somewhere that knows which
> > dead object to call with what parameters at exactly the right time.
> > (The only mechanism for managing this complexity is to create ever more
> > functions at ever higher levels of abstraction, or to have a
> > proliferation of nebulously-defined "manager" objects.)  IMHO once you
> > cross this chasm and are able to model your problem domain with live
> > objects that go off and automatically respond to the runtime
> > environment and Do the Right Thing, it's very hard to go back to a dead
> > object mindset.  I can understand, however, that until one makes this
> > leap, it might seem like an academic and useless distinction.
> >
> > -peter
> >
> Excellent post, Peter.  Thanks for great clarification. Looking from a
> physicist' perspective, im always trying to compare/evaluate languages
> from "the physical reality/dynamics" angle.  So, the run-time
> space/dynamics is the only one that matches the natural "always-runtime"
> objects - atoms, molecules, EM fields, biological cells(?).  It is the
> *reactive* world with event/forces-driven dynamics.  Seemingly, there is
> nothing beyond that, including biology.

A more conventional notion is that of static/dynamic properties of a
language. Component models that guarantee certain properties at compile
time are easily checked for consistency but to many programmers ( I
guess most of the programmers who attend to this list ) they are
inflexible: you might change or adapt your components according to
events, switch between entities, enable dynamic configuration etc. This
can be achieved in C++, Java etc. as well but not without pain.

BTW as a physicist you try to understand the "laws" i.e. the
mathematical structure behind all these diverse activities. Once you
understood the mathematical structure completely and fill  it with
inital- or boundary value parameters ( the code ) you know everything
about its "static behaviour" i.e. nature is turned into a logical
system ( measurement problem of QM aside ) where you deduce all future
events. But this constitutes only one half of modern science. The other
one is the experimental method. As far as I can say CS sticks currently
to the pre-Galilean metaphysics of a good god ( a good programmer /
engineer ) trying to establish systems that shine within the light of
formal purity. Although this has little relevance and not much to to
with the trilllions LOC all around us and instead of adjusting their
worldview CS academics tend to ponder about the "software crisis",
critizise industry for ignoring them and dismiss programmers who use
weird languages like Python without good formal properties. As you
already guess the lack of the experimental method does not even lead to
establishing some formality ( by means of hypothetic deductions in the
sense of Popper ) within basically informal ( untyped ) systems but to
succeedingly failed attempts of pre-established harmonies.