Re: Time to rewrite dpkg
On Thu, May 20, 1999 at 08:47:00PM +0200, Marek Habersack wrote:
>
> > The current dpkg is written in C. How many programmers are working on it?
> Again, that's not an argument. People come and people go, and more of them
> know C than C++. Besides, ech..., how can you draw an argument like this???
I can because I see what's happening to dpkg and it worries me.
We all are blinded by dpkg. It works, yes. How long? The current sources
don't even build properly out of the box. Problems are cropping up without
people knowing how to fix them (see the bug list). Even very simple patches
and changes need months to get into yet another non-maintainer release.
Your argument is that there would be a lot of more hypothetical programmers
for a C version. This is irrelevant as long as the real number of C
programmers willing to do this is 0 == NULL and the number of C++
programmers is at least 2, if not more.
> Is that a reason to write dpkg in Heskell, because the current maintainer
> fancies that?
You're exaggerating. What if someone would propose doing it in ZX 80
assembler and running it on an emulator? Yeah. Bad idea.
But there seem to be enough C++ deevelopers around here, and more and more
will follow (if you haven't noticed, on universities they teach Scheme, Java
, Perl and C++, depends on which faculty you are looking, AI, linguistics or
math/computer science).
> And what if he gets tired maintainig it?
I am absolutely sure that it would take me less effort to learn Huskell from
scratch and work on a very clean and well written Huskell version of dpkg
than to work on the current dpkg in C. Yes, I have taken a deep look into
the dpkg source. I even worked on some things.
> And what about
> compatibility? Extensibility? Interoperability? They don't matter at all,
> right?
In my book, yes. But compatibility which what? Extensible to where?
Your arguments are not really good ones, you can write good and bad code in
any language. But even if they were, they are hypothetical anyway. My proof:
The current dpkg is written in C. Is it compatible? No. I needed to fix a
lot of stuff to make it work on the Hurd, and it was a pain to find out how
to fix things. Is it exensible? Not easily, because the code is difficult to
follow. Is it interoperable? With what?
I don't want to make dpkg bad here. But you tell me how wonderful C code can
be, and how bad C++ code alwas can be, but I see dpkg, which is in C, and I
see apt, which is in C++, and I don't understand how you can be so sure
about that.
Using C does not grant you immediate success. It does not give you
compatibility for free. It does not give you extensibilty and operability.
Neither does C++.
You have to code it.
> > The only contributions to our packaging systems today are done with C++
> > (apt), and perl (install methods).
> Yes, yes. But you won't be able to use perl with C++ libraries.
Big deal. The current perl code does usually not use C libraries. They call
the executable. Great, eh?
Marcus
--
"The purpose of Free Software is Free Software.
The End and the Means are the same." -- Craig Sanders
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
Reply to: