Re: Python or Perl for a Debian maintainance project?
I'm assuming this is a serious discussion.
ma, 2004-02-16 kello 15:41, Andrew Suffield kirjoitti:
> On Sun, Feb 15, 2004 at 11:48:39PM +1100, Zenaan Harkness wrote:
> > To fill in the blanks in my ignorant mind, which language(s) out
> > there have not had versioning problems?
>
> C
We've had K&R C from 1978, various somewhat incompatible dialects in the
1980's (near/far being one of the smaller differences), the ANSI
standard from 1989 (adopted reformatted, but otherwise unchanged by ISO
in 1990), a normative addendum in 1995 (I think), and a new standard in
1999. Along the way, various vendors have made extensions to the
language (longer integer data types, inline, C++ comments, etc), as well
as occasionally being mutually incompatible. Pretty much every
implementation has extended the library, often in ways that are in
violation of the standard (adding new functions to standard-specified
headers).
As a result, we got autoconf.
I would not say that C has not had versioning problems. :)
On the other hand, the 1989 version of the C standard has been a great
stabilizing influence for fifteen years now. If you follow it strictly,
you can be quite confident that things will work. With only a little bit
of effort, you can do quite a lot and not have to ever have to deal with
autotools (assuming a semistandard Unix environment with cc and make).
Most programmer's don't do that, associating configure script length
with other lengths, but that's not an inherent problem with the
language.
On the whole, C has fewer versioning problems than the popular scripting
languages (Python, Perl, Tcl). I don't know Perl and Tcl, but as far as
Python is concerned, to the best of my knowledge the major reason we
have several Python release versions in a Debian release is that
extensions to the Python interpreter (e.g., bindings to various C
libraries such as GTK+) need to be compiled for each release series
(2.1, 2.2, 2.3) separately.
The Python language has changed and if you have a program written for
Python 2.3 that uses new language or library features, it won't work
with Python 2.2. If you avoid those, you don't have a problem. With very
few exceptions, a program written for Python 2.1 or 2.2 will work for
2.3, just like a C program written for the 1989 version of the standard
will work for the 1999 version. The exceptions tend to be in obscure
corners of the language, which you should avoid lurking in anyway. If a
newer version of Python breaks a Python application, it can often be
treated as a bug, in Python or in the application, and the situation
often can be rectified by fixing the bug. We had this with Mailman just
recently.
(We may also have a problem in how we package Python for Debian, but
that is a Debian problem, not inherent in Python.)
On a more philosophical note, most programming languages in active use
keeps changing and we need to adapt to that. Of course, mature languages
such as C, AWK, Perl5, or Common Lisp, probably don't change so often
that it matters in the daily life of maintaining Debian. New languages
change more often: they gather new users, with new needs, and need to
accomodate. This change process is quite acceptable and if it means we
need to have several implemenations of a particular language, so be it.
It would, of course, be preferable not to have to have them.
--
http://liw.iki.fi/liw/log/
Reply to: