This post originated from an RSS feed registered with Python Buzz
by Ian Bicking.
Original Post: GNOME and the Managed Runtime
Feed Title: Ian Bicking
Feed URL: http://www.ianbicking.org/feeds/atom.xml
Feed Description: Thoughts on Python and Programming.
He is bringing up some important issues, which I think can be
summarized with the question: what is the future of the free software
development environment?
Historically, of course, the environment has been primarily C. As
this has become less acceptable to software writers, efforts have
diverged into a number of different areas. But the "core" efforts,
the basic infrastructure upon which we build, has remained in C.
Except KDE's C++, but that's really the exception that proves the
point -- and certainly not an example of how we want to transition to
a different core environment (speaking from a social/political point
of view, not technically).
Even C has been a bit of an issue, as attempts to build up the
environment in C have met some resistance from people who don't want
to deal with a large number of dependencies. Of course, since I use
Debian I don't mind a large number of dependencies, and I'm only even
vaguely aware that dependencies exist. But apparently a significant
number of people are using inferior operating systems where this is a
problem.
Anyway, ignoring the issues of dependencies, the question of
environment is a very important one, and I think Havoc is right to
start to talk about it as a conscious decision. Anyway, my two cents:
I think many in the free software community -- especially those with a
desktop orientation -- have had an inferiority complex. They've heard
the message that free software can only play catch-up with proprietary
software, and for some reason they've come to actually believe this.
We need to start appreciating what we ("we" in the most inclusive
sense) have accomplished. Coming back to dependencies and Debian, I
think this is something that is an under-appreciated example of
success. Debian has something on the order of 10,000 packages in it,
all inside an inclusive system of developer support, bug tracking,
release management, and everything else that makes the operating
system work. This is built on technical foundations in part, but also
very much on social and political foundations.
I believe the result is simply the most maintainable, well-controlled
system of software ever. Ever! I feel confident that no one has
created a matching system, not inside a research facility, not on
mainframes, not in any of the other major operating systems. Because
you can't create something like that outside of a social structure,
and Debian simply has no peers in this.
This isn't a minor accomplishment either -- it gets to the foundation
of managing a computer system, as applicable to desktops as to
servers. It does so through technical means (which can be copied by
proprietary companies), but also through the incremental and
cooperative efforts of the Debian maintainers and users (which
cannot be copied). Obviously, robust software management isn't the
complete solution to all our woes, but it's a very important part of
the ultimate solution.
I don't bring that up because it directly informs the environment
debate -- though it does relate in some ways (in terms of creating
manageable eclectic environments) -- but because I see it as a
strategic example. Debian wasn't competing with Microsoft. I don't
even think people were comparing Debian to Microsoft at any time
during development. Debian did not compete on Microsoft's terms. And
as a result, they were able to create a system that excelled in a way
Microsoft could not excel.
We need to be doing the same when we consider environments. Here
we're looking at two proprietary environments -- Java and C# (and
arguably even C++ is proprietary in spirit) -- and asking which one is
best. That's a horrible strategy! Those environments were created
with strategic goals in mind, and those strategies hinge around
proprietary companies.
Instead we should be looking for inspiration from within our
community. We should be looking for the successes we have come up
with ourselves, based on a feedback cycle that includes free software
developers, and based on software methodologies that makes sense for
us (methodologies which are very different from proprietary
development).
An example: I think Python's model of portability is superior to
Java's -- Java is based on the idea that you can abstract away the
larger environment, so that every program will see the same thing no
matter what platform it is on. Python's model is that you expose the
platform's differences when they exist, and allow developers to create
portability layers at whatever level makes sense to them, or to use no
layer at all.
Java's model makes sense for proprietary development, because you may
test on only one platform, but a user can use it on another platform
with no changes. Python's model is superior for open source software,
because if the user has problems on their platform (which won't
necessarily happen, but can), then they can report the problem,
suggest whatever pragmatic fix is necessary, and it will work on the
next upgrade. Because there's a feedback loop, and because the user
is empowered through the presence of source code, Python can make
context-sensitive decisions about portability. The Python program can
then make full use of the platform it runs on, instead of using the
lowest common denominator, or creating entirely alternate layers (like
Swing).
I'm not familiar enough with desktop programming, or with Java or C#,
to come up with a lot of examples like this, but I suspect many exist.
Ultimately a solution equivalent to Java or C# isn't going to come out
of the free software community. But I think alternative solutions
already have come into existence, we just haven't always recognized
them because they don't map one-to-one to the proprietary
technologies.
Ultimately I've already made my choices, so it should be no surprise I
think Python is part of that solution. But only part. The larger
environment that favors Python is probably one built on C libraries.
This is in no small part because Python needs all the help in terms of
speed that it can get (at least for the desktop). Though the dumb
procedural libraries that C encourages also maps well to Python and
other environments, where we would prefer to be given a low-concept
library that can serve as the foundation of a higher-level library in
the native language (and this applies to all the high level
languages). Mapping a library from Java will be slightly less
comfortable, I think, due to almost-but-not-quite mappings. But I
don't have a lot of experience in this area, so maybe it works better
than I expect.
I've been happy reading about some of the projects like D-BUS which
seem to carry on in the tradition of low-concept libraries. Perhaps
what's need is a way of understanding and appreciating this model of
development -- layered, procedural, decoupled -- rather than
supplanting it with something more "advanced".
(Of course, I don't program in C, so maybe it's flippant for me to
say that I'm happy others are working in C, because those other people
might not be so happy to be in that environment.)
Previous Topic
