* Marcus Brinkmann said: > > 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. I aggree. I have looked into dpkg code and it scared me, yes...
> 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. You can count me in both groups - I have NO personal preference as to the language used, none at all. The tool doesn't matter that much, the effect does - and the more commonly acceptable, the better in that case. > > 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). Don't talk about universities. I've seen too many university graduates that know nothing about "real-world programming"... > > And what about > > compatibility? Extensibility? Interoperability? They don't matter at all, > > right? > > In my book, yes. But compatibility which what? Extensible to where? Compatibility with everything used to program - meaning, easy interfacing with other programming languages. Extensible to other environments, or simply put - creating frontends and utilities to easily manage the packages - vide gnomeapt for apt. > 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? Once again: I DON'T CARE WHAT LANGUAGE IS USED HERE. I just see that blind faith in any language can lead to a product which can be extended only in that language. And why to do that when you can a) DESIGN good procjec b) CODE it in C c) EXTEND it with virtually every other programming language Can't you see that C is simply a BASIS on wich you can build everything you imagine. Someone said C is "primitive" - true, but that's why it's so powerful. There are better designed languages out there, which have better theory behind them, true, but no language is so common as C, and as such (!!) it should be chose to create tools which are to be extended, either now or in the future. Look, how many years dpkg has been virtually in the center of the Debian dist??? And that's why you have to THINK ABOUT THE FUTURE and not discuss about what language is better for THEORETICAL reasons. We deal with practice, not with theory here. > 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. I'm starting to lose my nerve... I NEVER said that C is better or C++ is better IN GENERAL. I just think that C is better for THIS task and so far nobody convinced me that it cannot be done in C. It's all a matter of design, when we speak about the program/library itself, and not of the language chosen. But from the point of view of the final product, the language choice appears to be important since it will affect what tools can be used to FURTHER extend dpkg. > Using C does not grant you immediate success. It does not give you > compatibility for free. It does not give you extensibilty and operability. I never said it. > > > (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 Big deal you say? ^^^^^^^you said it. If the library is written well in C, then code in perl, tcl, scheme, elisp, java, whatever will use it because it will be EASIER this well. It all comes down to GOOD DESIGN. marek
pgp93xNXekGoa.pgp
Description: PGP signature
