* Marcus Brinkmann said: > This mail is ignoring Aaron's request for peace over this topic, but I am I just can't resist writing it: there was NO war on this subject, so why do you and Aaron want to make peace? > > become the new standard, then the language you decide to use is very > > important. > > Think of egcs. We really should be happy that someone is actually deciding egcs is a compiler which is not finished yet, it is (at least in respect with C++) incompatible with gcc... > to work on our package managment. Even if Aarons dpkg will not be the one > used in future Debian releases, it will have affect on the current dpkg. Of course, and nobody denies it. > > > extremely friendly towards C++ implementations, and much more powerful than > > > common interop mechanisms with conventional languages such as RPC. > > > > IMHO. What the best thing to do is write your libdpkg in C. Remember > > C is still the standard language for Unix. > > dpkg is not Unix. Do I have to say more? Dpkg is a package manager, and any > language can be chosen. If Aaron had said he would write it in Scheme, I > would have applauded it. If you tell me you want to write one, too, but in > Pascal, more power to you. Wrong. You're getting it all wrong. dpkg is a vital component of the Debian distribution and, as such, it should be written with future in mind! And future can bring a dozen of programmers who can extend dpkg in some way and using a dozen differend languages. Then CAN interface with a C library without any problems, then CANNOT interface a C++ library. Point. So, if you want dpkg to be interoperable, extensible and following the rule "everyone uses what language s/he likes", keep small size - you have to do it in C (all disscusions about which language is better put aside, ok?). > Of course, I am exagerrating. There are pros and contras for any language, > but it is silly to rule out anything beside C for historical reasons. You get it wrong again. It is not for HISTORICAL reasons, it's for the current status quo and the FACTS that speak in C's favor. > > And it will also allow a > > larger number of languages to possibily use those library calls. > > Who will write all these programs? Will you? The current libdpkg is written > in C, how many programs use it? If you say, that YOU are going to write > something in a language you need support for, you would have a point. Now, now! Those arguments are pretty inadequate, I'd say. Tell me, how many programs use libcap? Is that a reason why libcap should be dumped? And, I'm sure, there will be someone who will want to write the programs IF the library is well-designed, well-written and INTEROPERABLE. And the hypothaetical person will be free to chose the preferred language for his work - but it will not be possible when the library is in C++. > > It's your > > project and you can do what you like, but I believe that libdpkg > > should definately be written in C. > > Of course, you are entitled to your opinion. But the decisions are made by > people who to do the work. Not in this case. This is not their graduate project, nor an experiment. It's a package which the entire Debian distribution relies on - and that makes it a COMMON EFFORT no matter who writes the program. The decisions how to design and write the program should come from the developer community - a common sense is what we need. > > wrappers around libdpkg for that. > > C++ has problems, its size is one > > of them. > > The size of the language or the size of the binaries? binaries, of course. Who cares about the language? > The language was carefully designed to avoid bloat of the binaries. C++ does Dream. C++ does bloat programs. > not enforce any language feature on the programmer. The biggest size concern > are exceptions. But exceptions will make error handling oh so much simpler Not only. The IO library is really HUGE and you have to use it to be 100% C++. > and cleaner. About 50 percent of code is error handling. Use of exception > can reduce the amount of actual program code tremendously, which does > decrease the size of the program code (hence the binary). AND it is easier > to understand. You would be surprised what problems people have with all the try/catch blocks. > Use of the standard library is another point. The standard library makes the > program code easier, and really does not increase the overall code, because > if you don't use it, you have to replace it with your own code, which is a > source of errors, too. You are talking about things like STL or other template-based libraries? Then they will increase the binary size, and they will do it significantly. > > The other is, C++ is in a constant state of flux. > > This is plain wrong. > > Your knowledge of the C++ language is a few years behind of current > standards and implementation. C++ isn't in state of flux anymore, true, but egcs (and it's the only compiler around on the GNU platform which can be used to do serious C++ programming) is. Speaking of which, are you going to force everyone to use egcs? And explain every time someone cries "my code doesn't link with your code!!" that he should use egcs vX.X to link with the library vX.X.X and not gcc vX.X???? marek
Attachment:
pgpdRdSWogFcA.pgp
Description: PGP signature