[Fwd: Re: [Uuu-devel] languages] <-- Why Python

Paul Boddie paul at boddie.org.uk
Sun Feb 20 04:39:16 EST 2005


Mike Meyer <mwm at mired.org> wrote in message news:<86r7jdh5vw.fsf at guru.mired.org>...
> Arich Chanachai <macrocosm at fastmail.fm> writes:
> 
> > When the CLR is integrated, it will allow a wide array of problem
> > solving choices for uuu users.
> 
> You've missed the point. Allowing a wide array of problem solving
> choices is a goal, not a means. Instead of concentrating on adding
> langauges, you should be provding an infrastructure that makes adding
> langauges simple.  The Plan 9 example does this best, as any language
> that can do file I/O is supported.

This discussion collides quite nicely with two of the more quoted
articles on software development:

http://primates.ximian.com/~miguel/bongo-bong.html
http://www.jwz.org/doc/groupware.html

The first of which eventually addresses the issue of how programs
communicate with the operating system services and each other,
although I'm sure I've seen a more succinct overview from Mr De Icaza
on that subject. The second brings up the topic of making things
"enterprise-ready" - probably one of the more popular motivations for
introducing something like the CLR into a project which doesn't
necessarily need it and isn't yet familiar with it.

>From what I've seen of Unununium, the motivation for using Python
seems to stem from the way Python's runtime system provides services
which overlap with those of an operating system; programs can
dynamically import code, inspect the properties of such code, and
invoke such code reasonably safely (as opposed to the "jump to this
memory address" model of lower-level runtime systems), although these
features are not unique to Python - the Erlang runtime system is
apparently designed for use at this level, and the Java environment
(and presumably the CLR) provides introspection and dynamic loading
capabilities. I would also imagine that the development of Lisp
operating systems and environments was similarly motivated.

In contrast, the standard UNIX model of interprocess communication and
introspection, extended substantially by Plan 9 and more
conservatively by modern UNIX variants, is said to leave something to
be desired, and those wishing more informative details about the
interfaces exposed by programs and services usually end up putting
something more complicated on top - see the emergence of Bonobo, DCOP
and D-BUS.

Paul



More information about the Python-list mailing list