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 <[EMAIL PROTECTED]>
